Hi all,
are there any plans to add -fstack-clash-protection to
the hardening flags?
Martin
Adrian Bunk:
> On Fri, Jun 17, 2022 at 10:18:43AM +0200, Matthias Klose wrote:
...
>
> >...
> > Link time
> > optimizations are also at least turned on in other distros like Fedora,
> > OpenSuse (two years) and Ubuntu (one year).
> >...
> > The idea is to file wishlist bug reports for those 373
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Tue, 27 Aug 2019 14:18:12 +0200
Source: bart
Binary: bart libbart-dev octave-bart
Architecture: source
Version: 0.5.00-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team
Changed-By: Martin Uecker
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 11 Dec 2018 13:07:12 +0100
Source: bart
Binary: bart libbart-dev octave-bart
Architecture: source
Version: 0.4.04-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team
Changed-By: Martin Uecker
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Mon, 10 Dec 2018 14:32:26 +0100
Source: bart
Binary: bart libbart-dev octave-bart
Architecture: source
Version: 0.4.04-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team
Changed-By: Martin Uecker
kag...@lists.alioth.debian.org>
Changed-By: Martin Uecker <martin.uec...@med.uni-goettingen.de>
Description:
bart - tools for computational magnetic resonance imaging
libbart-dev - Development files for BART
octave-bart - Octave bindings for BART
Closes: 897466
Changes:
bart (0.4.03-2) unsta
kag...@lists.alioth.debian.org>
Changed-By: Martin Uecker <martin.uec...@med.uni-goettingen.de>
Description:
bart - tools for computational magnetic resonance imaging
libbart-dev - Development files for BART
octave-bart - Octave bindings for BART
Changes:
bart (0.4.03-1) unstable; ur
kag...@lists.alioth.debian.org>
Changed-By: Martin Uecker <martin.uec...@med.uni-goettingen.de>
Description:
bart-view - viewer for multi-dimensional complex-valued data
Closes: 851431
Changes:
bart-view (0.1.00-1) unstable; urgency=medium
.
* Initial release. (Closes: #851431)
Ch
kag...@lists.alioth.debian.org>
Changed-By: Martin Uecker <martin.uec...@med.uni-goettingen.de>
Description:
bart - tools for computational magnetic resonance imaging
libbart-dev - Development files for BART
octave-bart - Octave bindings for BART
Changes:
bart (0.4.02-2) unstable; ur
kag...@lists.alioth.debian.org>
Changed-By: Martin Uecker <martin.uec...@med.uni-goettingen.de>
Description:
bart - tools for computational magnetic resonance imaging
libbart-dev - Development files for BART
octave-bart - Octave bindings for BART
Changes:
bart (0.4.02-1) unstable; ur
kag...@lists.alioth.debian.org>
Changed-By: Martin Uecker <martin.uec...@med.uni-goettingen.de>
Description:
bart - tools for computational magnetic resonance imaging
libbart-dev - Development files for BART
octave-bart - Octave bindings for BART
Changes:
bart (0.4.00-1) unstable; ur
Package: wnpp
Severity: wishlist
Owner: Martin Uecker <martin.uec...@med.uni-goettingen.de>
* Package name: bart-view
Version : 0.0.01
Upstream Author : Martin Uecker <martin.uec...@med.uni-goettingen.de>
* URL : https://github.com/mrirecon/vie
kag...@lists.alioth.debian.org>
Changed-By: Martin Uecker <martin.uec...@med.uni-goettingen.de>
Description:
bart - tools for computational magnetic resonance imaging
libbart-dev - Development files for BART
octave-bart - Octave bindings for BART
Closes: 806762
Changes:
bart (0.3.00
Samuel Thibault:
Matthias Urlichs, le Thu 25 Sep 2014 21:17:58 +0200, a écrit :
Samuel Thibault:
Sounds crazy to me.
Definitely. This is now out in the wild; exploits which simply replace
echo or cat-without-/bin are going to happen. :-/
That's not so easy to exploit. You have to
Russ Allbery r...@debian.org:
Martin Uecker uec...@eecs.berkeley.edu writes:
While everybody is looking at bash, isn't this the real the injection
part? Why are there still programs which copy stuff from the network
into environment without proper sanitation?
The previous sanitization
Tollef Fog Heen wrote:
* Martin Uecker
[...]
| There was a thread building packages with exact binary matches
| about it. Unfortunately, most people seem to think that this is not
| worth it.
I don't think that's unfortunate; I think it's a waste of resources
better spent elsewhere
Tollef Fog Heen wrote:
* Martin Uecker
| Another problem I have argued about before, not directly related to this
| incident, but IMHO another desaster waiting to happen: There is no
| way to independetly validate that a debian binary package was
| created from the corresponding source
Kevin B. McCarty [EMAIL PROTECTED] wrote:
If you see packages for which a Debian-specific patch seems unnecessary,
please by all means file a bug (severity wishlist) requesting that the
patch be either reverted or submitted upstream.
Most time the patch is already submitted upstream, but
[EMAIL PROTECTED] wrote:
I disagree. The cause of the disaster was not that Debian does its own
patching, but the fact that that patch was buggy.
Buggy patches happen all the time. The question is, how could
something as bad as this slip through? And one important
reason is IMHO, that
martin f krafft [EMAIL PROTECTED] wrote:
[2] And IMO we should go further than patches.d.o, we need to create a
cross-distro infrastructure where we can share patches. We really have to
show the way here... (we complained enough that ubuntu patches were
unusable, surely we can show how to do
Barry deFreese wrote:
[...]
Buggy patches happen all the time. The question is, how could
something as bad as this slip through? And one important
reason is IMHO, that splitting up the development/bug fixing/review
by creating different software branches is bad.
Different software
Hi Kevin!
Kevin B. McCarty [EMAIL PROTECTED] wrote:
Martin Uecker wrote:
[...]
Well, *assuming* the patch is good, a subset of users of the software
(i.e. Debian users and users of downstream distributions) benefit from
it between the time it's applied in Debian and the time it's applied
Hi Michal!
Martin Uecker [EMAIL PROTECTED] wrote:
Upstream answered that it is okay too remove the seeding of the PRNG
with uninitialized memory, but the concrete patch which additionally and
erranously removed all seeding was never posted on openssl-dev.
Are you sure?
http
On Fri, May 16, 2008 at 11:26:01AM -0700, Don Armstrong wrote:
On Fri, 16 May 2008, Martin Uecker wrote:
Requiring distro specific changes feels wrong anyway. Software
should be coupled by standardized interfaces. But I might be naive
here. What are the distro specific changes we
Steinar H. Gunderson [EMAIL PROTECTED]:
On Thu, May 15, 2008 at 05:11:27AM +0200, Goswin von Brederlow wrote:
Also if you have 2 messages signed with the same random number you can
compute the secret key. It is more complicated then this but
simplified boils down to is computing k given
Am Donnerstag, den 15.05.2008, 15:20 +0200 schrieb Thijs Kinkhorst:
On Thursday 15 May 2008 14:04, Martin Uecker wrote:
If I understand this correctly, this means that not only should keys
generated with the broken ssl lib be considered compromised, but all
keys which were potentially used
Am Donnerstag, den 15.05.2008, 17:33 +0200 schrieb Thijs Kinkhorst:
On Thursday 15 May 2008 16:47, Martin Uecker wrote:
You mean less likely than once in 15 years? We're open to your
suggestions.
Something as bad as this might be rare, still, if something can be
improved, it should
On Fri, Sep 28, 2007 at 09:18:12PM -0500, Manoj Srivastava wrote:
On Fri, 28 Sep 2007 23:04:00 +0200, Martin Uecker [EMAIL PROTECTED] said:
There is some other thing I do not like about the way Debian packages
work. Every package I install can actually completely compromise my
system
On Thu, Sep 27, 2007 at 06:31:58PM -0500, Manoj Srivastava wrote:
On Thu, 27 Sep 2007 11:28:47 +0200, Martin Uecker [EMAIL PROTECTED] said:
[...]
But recompiling from what? If you do not get the exact same source,
you have no hope of getting the same result.
I had the impression
On Fri, Sep 28, 2007 at 09:05:59AM -0700, Don Armstrong wrote:
On Fri, 28 Sep 2007, Martin Uecker wrote:
You are seriously stating that is as easy to hide a trojan in the
source code as in the binary?
Consider the fact that we've already had such a case,[1] whereas we've
not (to my
Ben Finney [EMAIL PROTECTED] wrote:
Martin Uecker [EMAIL PROTECTED] writes:
On Tue, Sep 25, 2007 at 06:33:40PM -0500, Manoj Srivastava wrote:
Ah, security through blissful ignorance :) You do not
actually trust the archive, or the developers, you trust the
silence.
I
On Thu, Sep 27, 2007 at 02:26:49AM -0500, Manoj Srivastava wrote:
On Wed, 26 Sep 2007 12:31:51 +0200, Martin Uecker [EMAIL PROTECTED] said:
On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote:
Just because you have _heard_ anyone diss special relativity being
the sole
On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote:
On Wed, 26 Sep 2007 02:45:09 +0200, Martin Uecker [EMAIL PROTECTED] said:
[...]
No. I would trust the binaries if there are *no mails* from other
Ah, security through blissful ignorance :) You do not actually trust
On Mon, Sep 24, 2007 at 06:20:40PM -0500, Manoj Srivastava wrote:
On Tue, 25 Sep 2007 00:04:15 +0200, Martin Uecker [EMAIL PROTECTED] said:
It would be enough when just a few people are actually recompiling the
binaries and compare it to the official debian packages. Then
*everbody
On Tue, Sep 25, 2007 at 01:03:27AM +0100, Benjamin A'Lee wrote:
On Tue, Sep 25, 2007 at 12:04:15AM +0200, Martin Uecker wrote:
Manoj Srivastava [EMAIL PROTECTED] wrote:
Actually, if you do not trust the path down which a binary
package flows, you can not use any information down
On Tue, Sep 25, 2007 at 06:33:40PM -0500, Manoj Srivastava wrote:
On Tue, 25 Sep 2007 23:49:17 +0200, Martin Uecker [EMAIL PROTECTED] said:
On Mon, Sep 24, 2007 at 06:20:40PM -0500, Manoj Srivastava wrote:
On Tue, 25 Sep 2007 00:04:15 +0200, Martin Uecker [EMAIL PROTECTED]
said
Manoj Srivastava [EMAIL PROTECTED] wrote:
On Mon, 24 Sep 2007 04:56:45 +0200, Martin Uecker [EMAIL PROTECTED] said:
If policy would require the exact reproducability of binaries, then it
would be a policy violation.
That is not how things work around here. In a case like
On Mon, Sep 24, 2007 at 08:35:50PM +0200, Goswin von Brederlow wrote:
Martin Uecker [EMAIL PROTECTED] writes:
I think it would be really cool if the Debian policy required
that packages could be rebuild bit-identical from source.
At the moment, it is impossible to independly verify
Patrick Winnertz wrote:
Am Dienstag, 18. September 2007 21:12:44 schrieb Julien Cristau:
Hmmhh, what do you do about programs etc that encode the build-time in
the binary? I mean they obviously will change between builds?
Hopefully they don't encode the build-time in the file list?
We
Neil Williams [EMAIL PROTECTED]:
Martin Uecker [EMAIL PROTECTED] wrote:
[...]
I think it would be really cool if the Debian policy required
that packages could be rebuild bit-identical from source.
At the moment, it is impossible to independly verify the
integricity of binary
Joey Hess [EMAIL PROTECTED]:
Joerg Jaspert wrote:
On 11150 March 1977, Peter Eckersley wrote:
I've seen reports from very large sites indicating that
User-Agent
strings are almost as useful as cookies for tracking their
users.
I cant believe this. Looking at the stats
Benjamin A'Lee [EMAIL PROTECTED]:
On Mon, Sep 24, 2007 at 12:54:58AM +0200, Martin Uecker wrote:
Neil Williams [EMAIL PROTECTED]:
This has been covered before - certain upstream macros are among
many factors that ensure that this is unlikely. I, for one, use
such
macros upstream
On Mon, 24 Sep 2007 00:54:58 +0200
Martin Uecker [EMAIL PROTECTED] wrote:
Neil Williams [EMAIL PROTECTED]:
This has been covered before - certain upstream macros are among
many factors that ensure that this is unlikely. I, for one, use
such macros upstream to indicate the build
On Wed, Sep 15, 1999 at 01:19:34PM +0200, Paul Slootman wrote:
[...]
With dinstall a compromise is short lived and can be undone by erasing the
effected package. Creating a new key and getting people to sign it cannot
really be undone.
How do you prove to whoever is able to erase the
44 matches
Mail list logo
