Bug#709978: Add breaks to syslinux?
Actually, it might be helpful to add a Breaks: syslinux-themes-debian, syslinux-themes-debian-wheezy etc. to extlinux and syslinux. I'm unsure why the path has changed from /u/s/syslinux/themes to /u/s/EXTLINUX/themes (maybe because in the future themes would be incompatibles?), but just adding a symlink doesn't help, because the syslinux modules paths have changed, so all the symlinks in the themes have to be updated. I have no idea when them theme package is supposed to be updated, but in the meanwhile, and if it's easier, it might be wise to add that Breaks: so the theme is removed and it's still possible to run extlinux-update. And I'd advise to do it *before* the kernel name is updated in unstable, because at one point that could mean an unbootable system, if linux.cfg is not consistent with the currently installed kernels. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On lun., 2011-08-29 at 20:24 -0700, Josh Triplett wrote:
> On Mon, Aug 29, 2011 at 08:32:40PM -0500, Raphael Geissert wrote:
> > On Monday 29 August 2011 20:19:11 Josh Triplett wrote:
> > > Does OpenSSL not have any facility for a system-wide revocation
> list?
> >
> > No, I already checked that back when the Comodo hack occurred.
> > Every application needs to manually load the revocation lists, just
> like they
> > need to manually check the trust chain and all the other
> this-should-all-be-
> > done-in-just-one-place things.
>
> I understand that they'd have to manually load the lists, but perhaps
> it
> would make sense to standardize a location from which they should load
> them? Does OpenSSL or GnuTLS have any concept of a "revocation store"
> format, similar to a "certificate store", or would this need some
> special-purpose custom format?
And it'd be nice if nss could share that store...
nss apps are more or less starting to use a {/etc/,~/.}pki/nssdb/ which
can be shared accross apps (though I only know about evolution using it
right now).
By the way, shouldn't this bug be clone to libnss3-1d (and maybe
iceweasel and icedove if they ship the certificates themselves)?
Regards,
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On mar., 2011-08-30 at 12:29 -0500, Raphael Geissert wrote: > On Tuesday 30 August 2011 01:08:29 Yves-Alexis Perez wrote: > > On lun., 2011-08-29 at 20:24 -0700, Josh Triplett wrote: > > > I understand that they'd have to manually load the lists, but perhaps it > > > would make sense to standardize a location from which they should load > > > them? Does OpenSSL or GnuTLS have any concept of a "revocation store" > > > format, similar to a "certificate store", or would this need some > > > special-purpose custom format? > > AFAIR they only know about CRL (Certificate Revocation List,) which only > allows > for one issuer per-file. > > What I can't tell for sure from the documentation is whether OpenSSL and > GnuTLS do check the CRL's validity (signature and time.) It doesn't seem like > they do. > This is relevant if we were to ship them in ca-certificates. > > > > And it'd be nice if nss could share that store... > [...] > > > > By the way, shouldn't this bug be clone to libnss3-1d (and maybe > > iceweasel and icedove if they ship the certificates themselves)? > > Perhaps it's time to start a discussion as to how we can properly deal with > all this mess: > * Multiple packages shipping their own certificates list > * Probably no app except web browsers support CRLs and/or OCSP > * configuration > > Yves, do you know how the CRL stuff is handled in nss? > (my first name is Yves-Alexis :) I have no idea. There's a crlutil (http://www.mozilla.org/projects/security/pki/nss/tools/crlutil.html) but it works on previous database version (bdb, cert8.db and key3.db) while at least evolution now uses the shared sqlite db (cert9.db and key4.db, see https://wiki.mozilla.org/NSS_Shared_DB). Maybe Mike has some more ideas (adding him to CC:) Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On mar., 2011-08-30 at 22:48 +0200, Mike Hommey wrote: > > 1. Several fraudulent certificates whose fingerprint is unknown signed > with several different intermediate certs that are cross-signed by other > "safe" CAs (aiui). I missed that. What is the source for that? (i looked at the mozilla bug earlier but it lacks that level of precision) -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On dim., 2011-09-04 at 01:37 -0500, Raphael Geissert wrote: > On Saturday 03 September 2011 01:45:22 Mike Hommey wrote: > > Looking at the patches, this really is: > [...] > > Ok, with the patches we got NSS covered, but we still need to do something > for > other users. > > A first look at stuff we ship, this seems to be their current status: > * NSS: > ice* packages should be okay after the latest NSS update. For other NSS users I guess they're ok? I've just checked in evolution certificate store and there's no DigiNotar one, though I don't know if evolution would prevent connection to an imap/pop/smtp server with a relevant certificate. evolution uses gnutls for calendars (since it's http/https) and so is protected through ca-certificates afaict? > > * OpenSSL > Nothing special here > > * GnuTLS > Nothing special here > > * chromium: > Even after the NSS update, it seems to be happy to use the Explicitly > Distrusted certs. I've tried the tree websites given on this bug report but I don't know if they still make sense: https://www.diginotar.nl redirects to http://www.diginotar.nl/ (!!) but as the redirect isn't prevented I guess chromium is ok with the certificate. https://sha2.diginotar.nl/ succeeds, chain of certification is: CN = sha2.diginotar.nl CN = DigiNotar PKIoverheid CA Organisatie - G2 CN = Staat der Nederlanden Organisatie CA - G2 CN = Staat der Nederlanden Root CA - G2 (chromium builtin). Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On dim., 2011-09-04 at 13:34 -0500, Raphael Geissert wrote: > [Dropping CC on openssl maintainers, to reduce noise] > > On Sunday 04 September 2011 10:35:16 Yves-Alexis Perez wrote: > > On dim., 2011-09-04 at 01:37 -0500, Raphael Geissert wrote: > > > On Saturday 03 September 2011 01:45:22 Mike Hommey wrote: > > > > Looking at the patches, this really is: > > > [...] > > > > > > Ok, with the patches we got NSS covered, but we still need to do > > > something for other users. > > > > > > A first look at stuff we ship, this seems to be their current status: > > > * NSS: > > > ice* packages should be okay after the latest NSS update. > > > > For other NSS users I guess they're ok? I've just checked in evolution > > certificate store and there's no DigiNotar one, though I don't know if > > evolution would prevent connection to an imap/pop/smtp server with a > > relevant certificate. > > Did you look for "Explicitly Disabled DigiNotar..."? What do you mean? > > > evolution uses gnutls for calendars (since it's http/https) and so is > > protected through ca-certificates afaict? > > Not really, since DigiNotar's CA is cross-signed by Entrust and it probably > won't know that that signature has been revoked, since GnuTLS doesn't support > OCSP. > > That's the same sad story for everything else using GnuTLS and for many > OpenSSL users. OpenSSL does support OCSP, but applications rarely use it. Damn. > > > I've tried the tree websites given on this bug report but I don't know > > if they still make sense: > > > > https://www.diginotar.nl redirects to http://www.diginotar.nl/ (!!) but > > as the redirect isn't prevented I guess chromium is ok with the > > certificate. > > > > https://sha2.diginotar.nl/ succeeds, chain of certification is: > > > > CN = sha2.diginotar.nl > > CN = DigiNotar PKIoverheid CA Organisatie - G2 > > CN = Staat der Nederlanden Organisatie CA - G2 > > CN = Staat der Nederlanden Root CA - G2 (chromium builtin). > > From mozilla's bugzilla, these should also fail: > https://www.nifpnet.nl/ > https://belastingbalie.eindhoven.nl/ > https://acceptation.cbpublications.ingcommercialbanking.com/ > > (disable online recovation check before testing, at least the last one) None of them fail (the last one fails with revocation checking) Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On mar., 2011-09-06 at 07:33 +0200, Mike Hommey wrote: > On Mon, Sep 05, 2011 at 09:55:50PM +0200, Kurt Roeckx wrote: > > On Mon, Sep 05, 2011 at 02:15:31PM -0500, Raphael Geissert wrote: > > > On Sunday 04 September 2011 05:55:27 Kurt Roeckx wrote: > > > > On Sun, Sep 04, 2011 at 12:02:48PM +0200, Kurt Roeckx wrote: > > > > > Their is also openssl-blacklist, but it doesn't seem to have > > > > > much users. > > > > > > However, opensl-blacklist only includes a program that checks wether a > > > certificate is weak, nothing in it AFAICS actually blocks them. It's > > > basically > > > useless for this case. > > > > It could theoreticly also be used to block any certificate if > > we'd know the public key. But I agree it's useless for this case. > > Actually, if it was used at all levels of the cert chain, we could block > the CA certificates we want. And we do know their public key, contrary > to the rogue certs. > In case this was missed: http://www.f-secure.com/weblog/archives/2231.html (sorry, pastebin seems to be under attack right now or slashdotted right now, so http://pastebin.com/u/ComodoHacker is unavailable) Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#493090: News?
Hey? What's the status on this? I tried to install python-gnuplot just to draw some graphs, and same thing happened, apt wanted to install gconf daemon. I'd really appreciate not being forced to do that, and saw this bug. Is there an eta for the package upload? The “pending” tag was added in august, so…? Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
