On Thu, May 15, 2008 at 03:19:55PM +1200, Martin Langhoff wrote:
> I am looking at hosts that are runing other linuxen that may have weak
> keys now, or see those weak keys uploaded inadvertently in the future.
>
> Is there a straightforward way to get hosts that are !(Debian|Ubuntu)
> to use that
Eugeniy Meshcheryakov, 2008-05-16 02:10:39 +0200 :
> This can happen if user has 'default-mta' package installed, and it
> changes (if it is done like with 'gcc' package now).
Unless default-mta Depends: exim4 | mail-transport-agent. But that's
a bit ugly.
Roland.
--
Roland Mas
Fate always wi
On Thu, May 15, 2008 at 04:45:19PM -0700, Steve Langasek wrote:
> > 2) Introduce a default-mta package (currently) depending on exim4. All
> > packages requiring a MTA should depend on default-mta |
> > mail-transport-agent.
> > This will have the extra advantage that we (and others like CDDs a
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Thu, May 15, 2008 at 11:33:04PM +0200, Sune Vuorela wrote:
>
>> Noticing among others this bug report
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322751 and observing the
>> many packages depending on $MTA | mail-transport-agent with $MTA h
Peter Palfrader skrev:
On Thu, 15 May 2008, Norbert Preining wrote:
On Do, 15 Mai 2008, Mike Hommey wrote:
I beg to differ. This particular mail is important enough to be sent to
d-d-a instead of d-i-a.
I agree, dia is not what I would be subscribed to under normal
circumstances, and with all
On Thu, May 15, 2008 at 07:53:21AM -0700, Russ Allbery wrote:
> Guido Günther <[EMAIL PROTECTED]> writes:
> > On Thu, May 15, 2008 at 03:33:41PM +1000, Brian May wrote:
>
> >> Apparently, Heimdal in Debian also is affected. I am not aware of any
> >> solution other then to manually regenerate all
Package: wnpp
Severity: wishlist
Owner: Vincent Danjean <[EMAIL PROTECTED]>
* Package name: libbiblio-endnotestyle-perl
Version : 0.05
Upstream Author : Mike Taylor <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Biblio-EndnoteStyle/
* License : perl (GP
On Fri, May 16, 2008 at 08:41:25AM +0200, Norbert Preining wrote:
> On Do, 15 Mai 2008, Peter Palfrader wrote:
> > > > I beg to differ. This particular mail is important enough to be sent to
> > > > d-d-a instead of d-i-a.
> > >
> > > I agree, dia is not what I would be subscribed to under normal
Package: wnpp
Severity: wishlist
Owner: Debian Octave Group <[EMAIL PROTECTED]>
* Package name: octave-tsa
Version : 3.10.6
Upstream Author : Alois Schlögl
* URL : http://octave.sourceforge.net/tsa/index.html
* License : GPL2+
Programming Lang: Octave
Descri
"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,
Hello Raphael,
Unfortunately I had some personal problems that I was not best to keep
this package.
I agree with you, if I can not keep then not caught. I am putting the
package up for adoption.
In respect of other packages I will be updating them.
Regards,
Jose Carlos
2008/5/15 Raphael Hertzog
Hi,
Le 16 mai 08 à 13:48, Martin Uecker a écrit :
"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.
On Fri, May 16, 2008 at 08:55:34AM -0300, Jose Carlos Medeiros wrote:
> I agree with you, if I can not keep then not caught. I am putting the
> package up for adoption.
I'd be interested in this package as I have some issues with acpi
anyway. I won't be able to look into this before next week thou
Le vendredi 16 mai 2008 à 14:48 +0200, Thibaut Paumard a écrit :
> Let's hope this discussion will, in the end, bring good ideas and
> trigger actual work to improve Debian, and perhaps the free software
> community at large.
>
> Best regards, Thibaut.
>
>
That'd be great.
But please, ma
On Thu, May 15, 2008 at 06:28:36PM -0400, Filipus Klutiero wrote:
> I don't see your point.
I can have libfoo1 and libfoo2 installed and used at the same time so
both applications compiled for libfoo1 and libfoo2 can be used at the
same time. I can recompile my applications for libfoo2 as I get a
Le 16 mai 08 à 15:04, Olivier Berger a écrit :
Le vendredi 16 mai 2008 à 14:48 +0200, Thibaut Paumard a écrit :
Let's hope this discussion will, in the end, bring good ideas and
trigger actual work to improve Debian, and perhaps the free software
community at large.
Best regards, Thibaut.
Package: wnpp
Severity: wishlist
Owner: Bernd Schubert <[EMAIL PROTECTED]>
* Package name: unionfs-fuse
Version : 0.9.19~hg
Upstream Author : Radek Podgorny <[EMAIL PROTECTED]>, Bernd Schubert <[EMAIL
PROTECTED]>
* URL : http://podgorny.cz/moin/UnionFsFuse
* License
I've started http://wiki.debian.org/NewInLenny and would like to
invite y'all to populate the page with stuff that's changed between
etch and lenny. For now, I suppose just dumping anything to the end
of the list is good, we'll categorise later — but that's not to stop
anyone who wants to contribut
2008/5/16 Thibaut Paumard <[EMAIL PROTECTED]>:
> the topic has already been changed to "ssl security desaster", and in my
> opinion this is precisely what my post is about: what can we learn from this
> disaster. (More precisely, I'm giving my 2c on what level of patching is
> acceptable in a Debi
"Miriam Ruiz" <[EMAIL PROTECTED]> writes:
> Maybe there should also be a clasification of packages according to
> how bad would a bug be in them for the whole system, so that patches
> in those could be more carefully reviewed.
Perhaps uploads could come with the diff against the last version (or
Le 16 mai 08 à 15:41, Miriam Ruiz a écrit :
2008/5/16 Thibaut Paumard <[EMAIL PROTECTED]>:
[...] Maybe there should also be a
clasification of packages according to how bad would a bug be in them
for the whole system, so that patches in those could be more carefully
reviewed.
Actually, I see
On 16/05/08 at 15:41 +0200, Miriam Ruiz wrote:
> 2008/5/16 Thibaut Paumard <[EMAIL PROTECTED]>:
>
> > the topic has already been changed to "ssl security desaster", and in my
> > opinion this is precisely what my post is about: what can we learn from this
> > disaster. (More precisely, I'm giving
[Breaking the thread on purpose to start a new one]
On Fri, 16 May 2008, Lucas Nussbaum wrote:
> On 16/05/08 at 15:41 +0200, Miriam Ruiz wrote:
> > just reviewed by just one person, but then again, I seriously think
> > that it would have been quite difficult to discover that there was a
> > probl
On Thu, 15 May 2008, Steinar H. Gunderson wrote:
> On Wed, May 14, 2008 at 06:22:37PM -0500, Steve Greenland wrote:
> >> Therefore, anyone who had a DSA key has had it compromised...
> > Shouldn't that be "anyone who had a DSA key *created by the flawed
> > version of openssl* has had it compromis
[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 spli
On Fri, May 16, 2008 at 11:26 AM, nicolas vigier <[EMAIL PROTECTED]> wrote:
> On Thu, 15 May 2008, Steinar H. Gunderson wrote:
>> No. Any key who had a single DSA signature created by the flawed version of
>> OpenSSL should be considered compromised. DSA requires a secret, random
>> number as part
Please Cc [EMAIL PROTECTED] on this thread!
Including the full response for the list.
also sprach Raphael Hertzog <[EMAIL PROTECTED]> [2008.05.16.1654 +0100]:
> [Breaking the thread on purpose to start a new one]
>
> On Fri, 16 May 2008, Lucas Nussbaum wrote:
> > On 16/05/08 at 15:41 +0200, Miri
On Fri, May 16, 2008 at 05:26:09PM +0200, nicolas vigier wrote:
If I understand correctly, it means that if you use a good key with a
flawed openssl to connect to an other host using that key, then that
key can be considered compromised.
If I have a DSA key, and the client (my machine) has a ba
Martin Uecker wrote:
[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 importan
Hi Martin,
Martin Uecker wrote:
> "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 tim
2008/5/16 martin f krafft <[EMAIL PROTECTED]>:
> Please Cc [EMAIL PROTECTED] on this thread!
Done.
> also sprach Raphael Hertzog <[EMAIL PROTECTED]> [2008.05.16.1654 +0100]:
>> Add to this that each patch should have some standardized header on top
>> stating:
>> - a description of the patch and
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
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 softw
Hi
On Fri, 16 May 2008 19:28:52 +0200
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 y
On Fri, May 16, 2008 at 06:54:18PM +0200, Martin Uecker wrote:
> I am not convinced that more technological infrastructure is really
> the solution. Isn't simply the upstream source the right place for
> collaboration?
NACK, or better: ACK in theory, but not in practice. Sometime you have
wonderfu
martin f krafft <[EMAIL PROTECTED]> writes:
> Please Cc [EMAIL PROTECTED] on this thread!
>
> Including the full response for the list.
>
> also sprach Raphael Hertzog <[EMAIL PROTECTED]> [2008.05.16.1654 +0100]:
>> Add to this that each patch should have some standardized header on top
>> stating
On 19:51 Fri 16 May , Stefano Zacchiroli wrote:
> On the contrary, as the Debian counterpart I cannot point them to a
> single unified place where my patches are available. Or better, I can
> but just because all OCaml packages are stored in a single svn
> repository, with a clear defined polic
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 ap
also sprach Donnie Berkholz <[EMAIL PROTECTED]> [2008.05.16.1853 +0100]:
> http://patches.ubuntu.com/by-release/extracted/ contains patches
> for both Debian and Ubuntu. It's quite useful.
Lucas Nussbaum threw the idea of having a webpage with posisbly
annotated patches for each Debian package on
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?
> ht
Martin Uecker <[EMAIL PROTECTED]> writes:
> I don't now. I see no reason why all this good work which now ends up in
> Debian patches can't be seperated from the actual packaging work.
It's probably worth mentioning somewhere in this discussion that one of
the most common, perhaps the most common
On Fri, May 16, 2008 at 05:54:32PM +0200, Raphael Hertzog wrote:
> Add to this that each patch should have some standardized header on top
> stating:
> - a description of the patch and its purpose
, including pointers to relevant discussions, if any.
The idea is that anyone reviewing the patch get
Hi Martin,
I'm afraid this will be my last remark in this thread (do I hear cheers
from the crowd?) since I really should go do something more productive
now :-) Thanks for keeping the tone of discourse civil -- clearly this
is a subject you feel strongly about, and the problem that started the
t
Raphael Hertzog wrote:
> I totally agree that we need to make our changes more visible. In the
> openssl case, the patch in question is inside the .diff.gz and you don't
> notice it in the unpacked source package. I tend to give a look to what's
> in debian/patches/ when I rebuild a package but not
Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
> You're insinuatiog that a VCS does not allow easily browsing and
> examining patches, and I just don't buy it.
I can do more than insinuating: a VCS does not allow easily browsing and
examining patches. It doesn’t prevent it, but solely,
Russ Allbery wrote:
> Martin Uecker <[EMAIL PROTECTED]> writes:
>
>> In this case, the security advisory should clearly be updated. And all
>> advise about searching for weak keys should be removed as well, because
>> it leads to false sense of security. In fact, *all* keys used on Debian
>> machi
Josselin Mouette wrote:
> Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
> > You're insinuatiog that a VCS does not allow easily browsing and
> > examining patches, and I just don't buy it.
>
> I can do more than insinuating: a VCS does not allow easily browsing and
> examining patches
On Friday 16 May 2008, Joey Hess wrote:
> Raphael Hertzog wrote:
> > I totally agree that we need to make our changes more visible. In the
> > openssl case, the patch in question is inside the .diff.gz and you don't
> > notice it in the unpacked source package. I tend to give a look to what's
> > i
Package: wnpp
Severity: wishlist
Owner: Franck Joncourt <[EMAIL PROTECTED]>
* Package name: libiptables-chainmgr-perl
Version : 0.6
Upstream Author : Michael Rash <[EMAIL PROTECTED]>
* URL : http://www.cipherdyne.org/modules/
* License : GPL, Artistic
Progra
On Friday 16 May 2008, Joey Hess wrote:
> Josselin Mouette wrote:
> > Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
> > > You're insinuatiog that a VCS does not allow easily browsing and
> > > examining patches, and I just don't buy it.
> >
> > I can do more than insinuating: a VCS doe
Josselin Mouette wrote:
> Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
>> You're insinuatiog that a VCS does not allow easily browsing and
>> examining patches, and I just don't buy it.
>
> I can do more than insinuating: a VCS does not allow easily browsing and
> examining patches.
Adam Majer <[EMAIL PROTECTED]> writes:
> Clear patches are not because of VCS, but because of clear and concisely
> described changesets. If you have patches with bad descriptions or a
> giant blob in VCS, then that is useless not because of the failure of
> VCS, but the failure of the developer.
Daniel Burrows wrote:
> I notice that pwsafe is linked against openssl. Is it affected by the
> recent debacle and if so, how? Do I need to regenerate all my
> randomized passwords, or somehow re-encrypt the pwsafe database?
I've looked briefly into it: The Blowfish encryption key is construct
On Fri, 16 May 2008, Joey Hess wrote:
> Raphael Hertzog wrote:
> > To me this one proof more than even when VCS are used to maintain
> > packages, our source packages must clearly identify the Debian patches
> > that are applied.
>
> You're insinuatiog that a VCS does not allow easily browsing and
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> But don't get me wrong, I'm not opposed to using VCS for package
> maintainance (I do it!), I just think that we haven't found the perfect
> workflow yet.
In fact, despite being one of the big quilt advocates in the last round of
this discussion, I am
* 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.
How would you go about doing th
On Fri, 16 May 2008, Joey Hess wrote:
> Coming up with a complex set of requirements that everyone has to follow
> up front in their workflow[1] is not going to yeld the best results, and
> I think that's my core reason for disliking Raphael's proposal. Now, if
> you can come up with protocols/inte
Tollef Fog Heen <[EMAIL PROTECTED]> writes:
> * Martin Uecker
> | What bothers me too is the fact that the installer scripts of all
> | packages have root permissions during installation. While this might
> | be hard to do, in principle I see no good reason why installer
> | scripts could not be
On Fri, 16 May 2008 22:10:36 +0200, Josselin Mouette <[EMAIL PROTECTED]> said:
> Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
>> You're insinuatiog that a VCS does not allow easily browsing and
>> examining patches, and I just don't buy it.
> I can do more than insinuating: a VCS d
On Fri, 16 May 2008 14:39:56 -0700, Russ Allbery <[EMAIL PROTECTED]> said:
> Adam Majer <[EMAIL PROTECTED]> writes:
>> Clear patches are not because of VCS, but because of clear and
>> concisely described changesets. If you have patches with bad
>> descriptions or a giant blob in VCS, then that i
2008/5/16 martin f krafft <[EMAIL PROTECTED]>:
> Lucas Nussbaum threw the idea of having a webpage with posisbly
> annotated patches for each Debian package on *.debian.org at me the
> other day, in response to the OpenSSL debacle. I really liked it!
I think it would be a great Idea, but the poin
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Create a submission branch. There are two audiences for your
> work; one is downstream (which includes the integration branch for
> Debian), the other is upstream, one audience does not like rebases, the
> other thrives on it. See
> http:
On Sat, 17 May 2008 00:19:59 +0300, George Danchev <[EMAIL PROTECTED]> said:
> I personally don't think there is any need for new infrastrutures. We
> only need to follow some simple rules, i.e. orig.tar.gz should be
> really the original upstream source; diff.gz (debian/patches/
> included) is w
On 11387 March 1977, Martin Uecker wrote:
> Nevertheless, the right thing in my opinion would have been to
> propose a patch, wait until it is accepted, and then to package
> the new upstream version.
If you want that - build an own distribution. Or well - an LFS.
Because thats *not* what a distr
On Fri, 16 May 2008 23:27:03 +0300, George Danchev <[EMAIL PROTECTED]> said:
> On Friday 16 May 2008, Joey Hess wrote:
>> Raphael Hertzog wrote:
>> > I totally agree that we need to make our changes more visible. In
>> > the openssl case, the patch in question is inside the .diff.gz and
>> > you
Hi
Dne Fri, 16 May 2008 20:59:44 +0200
Martin Uecker <[EMAIL PROTECTED]> napsal(a):
> I don't see a patch there. This might sound like nitpicking, but
> a real patch would have provided some context to the two lines.
Yes there is no context, but it is patch and it is clear that it wants
to remov
On Fri, May 16, 2008 at 05:08:31PM -0500, Manoj Srivastava wrote:
> I am not sure I can agree. I find examining a single patch deep
> down in a quilt series very hard, unless I learn and use quilt, since
> the patches are all linearized, and each patch is dependent on th
> previous patch
On Saturday 17 May 2008, Manoj Srivastava wrote:
> On Fri, 16 May 2008 23:27:03 +0300, George Danchev <[EMAIL PROTECTED]> said:
> > On Friday 16 May 2008, Joey Hess wrote:
> >> Raphael Hertzog wrote:
> >> > I totally agree that we need to make our changes more visible. In
> >> > the openssl case, t
On Saturday 17 May 2008, Manoj Srivastava wrote:
> On Sat, 17 May 2008 00:19:59 +0300, George Danchev <[EMAIL PROTECTED]> said:
> > I personally don't think there is any need for new infrastrutures. We
> > only need to follow some simple rules, i.e. orig.tar.gz should be
> > really the original ups
Le May 16, 2008 09:10:35 am Lennart Sorensen, vous avez écrit :
> On Thu, May 15, 2008 at 06:28:36PM -0400, Filipus Klutiero wrote:
> > I don't see your point.
>
> I can have libfoo1 and libfoo2 installed and used at the same time so
> both applications compiled for libfoo1 and libfoo2 can be used
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 are talking about?
It'd be great[0] if we never had to do distribution spe
I went again through the mips build problems and collected the appended
list which records the current state, with a few annotations added.
Thiemo
Debian mips port, status 2007-05-16. See also:
http://buildd.debian.org/~jeroen/status/architecture.php?suite=unstable&a=mips&priority=
Architecture
George Danchev <[EMAIL PROTECTED]> writes:
> A large number of packages do not follow that simple rule, but patching
> the orig.tar.gz instead.
I have never seen a package that does this apart from DFSG-freeness issues
and a few beginner mistakes. The Debian changes are separated out in our
sour
On Fri, May 16, 2008 at 02:55:58PM +0200, Michael Meskes wrote:
>I'd be interested in this package as I have some issues with acpi
>anyway. I won't be able to look into this before next week though. If
>anyone else's interested I'd happily be part of a team.
Good.
I'm already working on acpid fix
On Sat, 17 May 2008, George Danchev wrote:
> On Saturday 17 May 2008, Manoj Srivastava wrote:
> > This is exactly what happened in the openssl case (modulo
> > ./debian/patches).
>
> Not true. openssl packaging didn't and still does not use clearly
> identified diff files in debian/patches/.
Uh..
On Fri, 16 May 2008 15:49:25 -0700, Russ Allbery <[EMAIL PROTECTED]> said:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> Create a submission branch. There are two audiences for your work;
>> one is downstream (which includes the integration branch for Debian),
>> the other is upstream, one au
Roland Mas <[EMAIL PROTECTED]> writes:
> - Keys submitted through the web interface are now filtered, and only
> RSA keys end up in your authorized_keys file. Don't even try
> putting DSA keys in your authorized_keys2 file, the use of that file
> has been disabled (and it'll be deleted anyw
On Fri, 16 May 2008 15:25:11 -0700, Russ Allbery <[EMAIL PROTECTED]> said:
> Raphael Hertzog <[EMAIL PROTECTED]> writes:
>> But don't get me wrong, I'm not opposed to using VCS for package
>> maintainance (I do it!), I just think that we haven't found the
>> perfect workflow yet.
> In fact, desp
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 ar
Le Fri, May 16, 2008 at 09:18:56PM +0200, Agustin Martin a écrit :
> On Fri, May 16, 2008 at 05:54:32PM +0200, Raphael Hertzog wrote:
> > Add to this that each patch should have some standardized header on top
> > stating:
> > - a description of the patch and its purpose
> , including pointers to r
On Fri, 2008-05-16 at 15:49:25 -0700, Russ Allbery wrote:
> That would work, although it does... well, not double, but at least
> increase the work for any branch that also has a submission branch, since
> any upstream merge conflicts have to be resolved on both branches. Or is
> there some way to
Quoting Raphael Hertzog ([EMAIL PROTECTED]):
> On Fri, 16 May 2008, Joey Hess wrote:
> > Coming up with a complex set of requirements that everyone has to follow
> > up front in their workflow[1] is not going to yeld the best results, and
> > I think that's my core reason for disliking Raphael's pr
On Fri, May 16, 2008 at 03:27:42PM -0500, Adam Majer wrote:
> Russ Allbery wrote:
> > Martin Uecker <[EMAIL PROTECTED]> writes:
> >
> >> In this case, the security advisory should clearly be updated. And all
> >> advise about searching for weak keys should be removed as well, because
> >> it leads
On Sat, May 17, 2008 at 12:45:20AM +0200, Miriam Ruiz wrote:
> 2008/5/16 martin f krafft <[EMAIL PROTECTED]>:
>
> > Lucas Nussbaum threw the idea of having a webpage with posisbly
> > annotated patches for each Debian package on *.debian.org at me the
> > other day, in response to the OpenSSL deba
84 matches
Mail list logo
