DigiNotar recently issued a fraudulent certificate [1] for *.google.com [2] There's a request in the Debian Bug tracker ($URL) to remove the CA from ca-certificates. I'm filing this bug to track the issue until they have decided about the request. [1] http://pastebin.com/ff7Yg663 [2] http://www.h-online.com/open/news/item/Fraudulent-certificate-triggers-blocking-from-software-companies-1333088.html
i think the phrasing is off slightly, but critically. diginotar's own website indicates that they didnt issue it but rather were the subject of an attack on their systems. http://www.vasco.com/company/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx also, punting their root cert would probably break many official Dutch gov't websites. sounds like a crappy situation.
(In reply to comment #1) > > also, punting their root cert would probably break many official Dutch gov't > websites. sounds like a crappy situation. Mozilla has announced to remove it from upcoming releases: http://blog.mozilla.com/security/2011/08/29/fraudulent-google-com-certificate/
my point was that the wording could have an impact on the decision. bad signing authority not checking credentials -> punt its certs (e.g. comodo) system that got hacked -> revoke hacked certs of course, if upstream Debian ca-certificates decides to drop it, that's fine by me as it's one less thing to deal with
(In reply to comment #3) > of course, if upstream Debian ca-certificates decides to drop it, that's fine > by me as it's one less thing to deal with ca-certificates-20110502+nmu1 was released: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639744#58
20110502 is in, but please double check if it's the nmu or not, I don't see the nmu on the mirrors that I looked at.
The 20110502 currently in tree is not the nmu1 version, and it does install the DigiNotar certificate as trusted. I found the nmu1 version at [1]. Simply adding '+nmu1' after ${PV} in SRC_URI installs the mnu1 version with DigiNotar blacklisted for me. [1] http://packages.debian.org/sid/ca-certificates
Created attachment 285201 [details, diff] Adds -r1 version with nmu1 update
Comment on attachment 285201 [details, diff] Adds -r1 version with nmu1 update dont do this. while we want to see patches, we actually want the diff showing the exact change made, not a file-in-disguise-as-a-patch. i.e.: --- ca-certificates-20110502.ebuild +++ ca-certificates-20110502.ebuild @@ -6,7 +6,7 @@ DESCRIPTION="Common CA Certificates PEM files" HOMEPAGE="http://packages.debian.org/sid/ca-certificates" -SRC_URI="mirror://debian/pool/main/c/${PN}/${PN}_${PV}_all.deb" +SRC_URI="mirror://debian/pool/main/c/${PN}/${PN}_${PV}+nmu1_all.deb" LICENSE="MPL-1.1" SLOT="0"
new version in the tree now. Ready for stable + GLSA.
Arches, please test and mark stable: =app-misc/ca-certificates-20110502-r1 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
Not a blocker, but is a bit to open a new bug. Please fix: dependency.unknown : app-misc/ca-certificates/ca-certificates-20110502-r1.ebuild: DEPEND: sys-apps/mktemp app-misc/ca-certificates/ca-certificates-20110502-r1.ebuild: RDEPEND: sys-apps/mktemp there isn't mktemp in tree. amd64 ok
not a bug
Stable on alpha.
Confirmed also for x86.
+ 01 Sep 2011; Tony Vroon <chainsaw@gentoo.org> + ca-certificates-20110502-r1.ebuild: + Marked stable on AMD64 based on arch testing by Agostino "ago" Sarubbo in + security bug #381169 filed by Alex "a3li" Legler.
This ebuild warned me about using UTF-8 (which I already do!) which I thought was odd. It also points users to this localization guide: http://www.gentoo.org/doc/en/guide-localization.xml But that guide is well out-dated - referencing files that no-longer exist after the updated baselayout+openrc
The stable version of dev-libs/nss share the same security problem (so xulrunner...). mozilla/security/nss/lib/ckfw/builtins/certdata.txt mozilla/security/nss/lib/ckfw/builtins/certdata.c
(In reply to comment #16) no idea what you're talking about. this ebuild has nothing to do with charset encodings or localization.
Stable for HPPA.
(In reply to comment #18) > (In reply to comment #16) > > no idea what you're talking about. this ebuild has nothing to do with charset > encodings or localization. I think he meant that: * This package installs one or more file names containing characters that * do not match your current locale settings. The current setting for * filesystem encoding is 'ANSI_X3.4-1968'. * * usr/share/ca-certificates/mozilla/AC_Ra\ufffd\ufffdz_Certic\ufffd\ufffdmara_S.A..crt * usr/share/ca-certificates/mozilla/EBG_Elektronik_Sertifika_Hizmet_Sa\ufffd\ufffdlay\ufffd\ufffdc\ufffd\ufffds\ufffd\ufffd.crt * usr/share/ca-certificates/mozilla/NetLock_Arany_=Class_Gold=_F\ufffd\ufffdtan\ufffd\ufffds\ufffd\ufffdtv\ufffd\ufffdny.crt * usr/share/ca-certificates/mozilla/T\ufffd\ufffdB\ufffd\ufffdTAK_UEKAE_K\ufffd\ufffdk_Sertifika_Hizmet_Sa\ufffd\ufffdlay\ufffd\ufffdc\ufffd\ufffds\ufffd\ufffd_-_S\ufffd\ufffdr\ufffd\ufffdm_3.crt ppc/ppc64 stable
arm/ia64/m68k/s390/sh/sparc/x86 stable
Thanks, everyone. GLSA Vote: no.
Probably not a bug, but: /usr/share/ca-certificates/mozilla/IGC_A.crt and /usr/share/ca-certificates/gouv.fr/cert_igca_rsa.crt are identical, update-ca-certificates issues a warning.
(In reply to comment #22) really ?? (In reply to comment #23) new issue -> new bug
Added to pending GLSA request.
This issue was resolved and addressed in GLSA 201412-09 at http://security.gentoo.org/glsa/glsa-201412-09.xml by GLSA coordinator Sean Amoss (ackle).
