[prev in list] [next in list] [prev in thread] [next in thread]
List: netbsd-tech-pkg
Subject: Re: DEPENDS+= mozilla-rootcerts (Re: ham/trustedQSL)
From: matthew sporleder <msporleder () gmail ! com>
Date: 2013-12-07 18:21:27
Message-ID: CAHKF-AtWq3RO4aERq+XOap5SrTZUmzC7g5CJqaj6K8y-D3nuDw () mail ! gmail ! com
[Download RAW message or body]
On Sat, Dec 7, 2013 at 8:24 AM, Greg Troxel <gdt@ir.bbn.com> wrote:
>
> Benny Siegert <bsiegert@gmail.com> writes:
>
> > On Sat, Dec 7, 2013 at 2:18 AM, Makoto Fujiwara <makoto@ki.nu> wrote:
> >> To process this part properly, following steps are necessary (I
> believe),
> >> (1) # pkg_add mozilla-rootcerts (not if DEPENDS in Makefile)
> >> and after reading 'pkg_info -D mozilla-rootcerts' or so,
> >> (2) # mozilla-rootcerts install
> >
> > I have argued in the past for automatically doing the "install" step,
> > as the package is basically useless otherwise. But there has been
> > resistance from people saying that certificate lists are config files
> > and should be installed manually by the administrator.
> >
> > Personally, I believe that this represents a non-obvious hoop to jump
> > through for a normal user. Probably 90% of people who install the
> > mozilla-rootcerts package do not care about any of these subtleties,
> > they just want the damn certificate warnings to go away.
> >
> > (This is why I wrote the install mode, by the way. Before that, the
> > instructions were like "just execute these ten simple commands".)
>
> This is a difficult question. The idea that one's system will have
> additional trust anchors (for all programs that use openssl) because one
> installed some random package that one didn't even think about whethet
> it uses ssl is nonobvious and surprising from a security viewpoint.
>
> Perhaps NetBSD's base system should have configured trust anchors
> instead; this isn't really about pkgsrc. Or perhaps we don't want to
> and we want to make users think about which CAs they trust. So I tend
> to think that the approach of not having programs depend on
> mozilla-rootcerts is better, and "how to think about what to do about
> trust anchors" is really part of system setup (or is part of the
> system).
>
> I wouldn't mind if mozilla-rootcerts does the install step
> automatically. But then I think we should have a rule that packages may
> not depend on it, so it only gets installed intentionally.
>
> The underlying problem is that the entire SSL/CA ecosystem is goofy (the
> many-CA, failure of any of which leads to compromise situation, not the
> PKIX protocols).
>
> The idea that we configure trust anchors to hide warnings, and we're not
> talking about security issues is a clue as to how bad the situation is.
> Certainly programs that don't like annoying warnings could perhaps
> configure them off, but presumably there is some intent to get the
> security properties SSL promises (but doesn't really deliver on).
>
> We avoid this issue in firefox (or rather, delegate it to mozilla) by
> having mozilla use it's own configured list of trust anchors rather than
> the system ones. On Mac, the system keychain comes preconfigured with a
> vast number of CAs, and wget from pkgsrc seems to use that system
> keychain.
>
> I am curious what the other BSDs and Linux systems do.
>
mozilla-rootcerts are defacto-installed into /etc by many linux systems
I've encountered, probably by being a dependency from any number of
packages, like openssl. :)
http://rpmfind.net//linux/RPM/mageia/cauldron/x86_64/media/core/release/openssl-1.0.1e-5.mga4.x86_64.html
depends on 'rootcerts':
http://rpmfind.net/linux/rpm2html/search.php?query=rootcerts
http://rpmfind.net//linux/RPM/centos/6.5/x86_64/Packages/openssl-1.0.1e-15.el6.x86_64.html
depends on 'ca-certificates<http://rpmfind.net/linux/rpm2html/search.php?query=ca-certificates>
'
eventually landing on:
http://rpmfind.net/linux/rpm2html/search.php?query=config%28ca-certificates%29
etc
http://packages.debian.org/wheezy/openssl
suggests
http://packages.debian.org/wheezy/ca-certificates
I don't use debian enough to say what that means, but I'm pretty sure you
end up with mozilla rootcerts.
[Attachment #3 (text/html)]
<div dir="ltr">On Sat, Dec 7, 2013 at 8:24 AM, Greg Troxel <span dir="ltr"><<a \
href="mailto:gdt@ir.bbn.com" target="_blank">gdt@ir.bbn.com</a>></span> \
wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div class=""><div class="h5"><br>
Benny Siegert <<a href="mailto:bsiegert@gmail.com">bsiegert@gmail.com</a>> \
writes:<br> <br>
> On Sat, Dec 7, 2013 at 2:18 AM, Makoto Fujiwara <<a \
href="mailto:makoto@ki.nu">makoto@ki.nu</a>> wrote:<br> >> To process this \
part properly, following steps are necessary (I believe),<br> >> (1) # pkg_add \
mozilla-rootcerts (not if DEPENDS in Makefile)<br> >> and after reading \
'pkg_info -D mozilla-rootcerts' or so,<br> >> (2) # mozilla-rootcerts \
install<br> ><br>
> I have argued in the past for automatically doing the "install" \
step,<br> > as the package is basically useless otherwise. But there has been<br>
> resistance from people saying that certificate lists are config files<br>
> and should be installed manually by the administrator.<br>
><br>
> Personally, I believe that this represents a non-obvious hoop to jump<br>
> through for a normal user. Probably 90% of people who install the<br>
> mozilla-rootcerts package do not care about any of these subtleties,<br>
> they just want the damn certificate warnings to go away.<br>
><br>
> (This is why I wrote the install mode, by the way. Before that, the<br>
> instructions were like "just execute these ten simple commands".)<br>
<br>
</div></div>This is a difficult question. The idea that one's system will \
have<br> additional trust anchors (for all programs that use openssl) because one<br>
installed some random package that one didn't even think about whethet<br>
it uses ssl is nonobvious and surprising from a security viewpoint.<br>
<br>
Perhaps NetBSD's base system should have configured trust anchors<br>
instead; this isn't really about pkgsrc. Or perhaps we don't want to<br>
and we want to make users think about which CAs they trust. So I tend<br>
to think that the approach of not having programs depend on<br>
mozilla-rootcerts is better, and "how to think about what to do about<br>
trust anchors" is really part of system setup (or is part of the<br>
system).<br>
<br>
I wouldn't mind if mozilla-rootcerts does the install step<br>
automatically. But then I think we should have a rule that packages may<br>
not depend on it, so it only gets installed intentionally.<br>
<br>
The underlying problem is that the entire SSL/CA ecosystem is goofy (the<br>
many-CA, failure of any of which leads to compromise situation, not the<br>
PKIX protocols).<br>
<br>
The idea that we configure trust anchors to hide warnings, and we're not<br>
talking about security issues is a clue as to how bad the situation is.<br>
Certainly programs that don't like annoying warnings could perhaps<br>
configure them off, but presumably there is some intent to get the<br>
security properties SSL promises (but doesn't really deliver on).<br>
<br>
We avoid this issue in firefox (or rather, delegate it to mozilla) by<br>
having mozilla use it's own configured list of trust anchors rather than<br>
the system ones. On Mac, the system keychain comes preconfigured with a<br>
vast number of CAs, and wget from pkgsrc seems to use that system<br>
keychain.<br>
<br>
I am curious what the other BSDs and Linux systems do.<br>
</blockquote></div><br><br></div><div class="gmail_extra">mozilla-rootcerts are \
defacto-installed into /etc by many linux systems I've encountered, probably by \
being a dependency from any number of packages, like openssl. :)<br> <br><a \
href="http://rpmfind.net//linux/RPM/mageia/cauldron/x86_64/media/core/release/openssl- \
1.0.1e-5.mga4.x86_64.html">http://rpmfind.net//linux/RPM/mageia/cauldron/x86_64/media/core/release/openssl-1.0.1e-5.mga4.x86_64.html</a><br>
</div><div class="gmail_extra">depends on 'rootcerts':<br><a \
href="http://rpmfind.net/linux/rpm2html/search.php?query=rootcerts">http://rpmfind.net/linux/rpm2html/search.php?query=rootcerts</a><br><br><a \
href="http://rpmfind.net//linux/RPM/centos/6.5/x86_64/Packages/openssl-1.0.1e-15.el6.x \
86_64.html">http://rpmfind.net//linux/RPM/centos/6.5/x86_64/Packages/openssl-1.0.1e-15.el6.x86_64.html</a><br>
</div><div class="gmail_extra">depends on '<a \
href="http://rpmfind.net/linux/rpm2html/search.php?query=ca-certificates">ca-certificates</a>'<br></div><div \
class="gmail_extra">eventually landing on: <a \
href="http://rpmfind.net/linux/rpm2html/search.php?query=config%28ca-certificates%29"> \
http://rpmfind.net/linux/rpm2html/search.php?query=config%28ca-certificates%29</a><br>
<br></div><div class="gmail_extra">etc<br><br><a \
href="http://packages.debian.org/wheezy/openssl">http://packages.debian.org/wheezy/openssl</a><br>suggests<br><a \
href="http://packages.debian.org/wheezy/ca-certificates">http://packages.debian.org/wheezy/ca-certificates</a><br>
<br></div><div class="gmail_extra">I don't use debian enough to say what that \
means, but I'm pretty sure you end up with mozilla rootcerts.<br></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic