Re: signed packages
Em 27-01-2014 01:33, Nicolai escreveu: > All the TLD and other massive outages say otherwise. I can think of > one project that uses DNSSEC to verify files via TXT lookups. Their > last DNSSEC outage? 3 days ago. Ed25519 in signify provides a 128-bit > security level and is decentralized. DNSSEC provides 112 bits at best, > via a government-controlled hierarchy. Nicolai I mentioned before that DNSSEC isn't perfect. Even IETF recognizes this and they have indicated that they will improve the situation. When, and how is a mystery. The thing is, that DNSSEC adds in security. Even with all it's problems. It would be one thing else to compromise. There is no ultimately trust in real life, why there would be in the internet? I wont die if they don't add it. Just will keep doing the same things and hoping that I did not were compromised. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: signed packages
On Thu, Jan 23, 2014 at 02:33:56PM -0200, Giancarlo Razzolini wrote: > DNSSEC would make things a little simpler All the TLD and other massive outages say otherwise. I can think of one project that uses DNSSEC to verify files via TXT lookups. Their last DNSSEC outage? 3 days ago. Ed25519 in signify provides a 128-bit security level and is decentralized. DNSSEC provides 112 bits at best, via a government-controlled hierarchy. Nicolai
Re: signed packages
Em 23-01-2014 09:33, Kevin Chadwick escreveu: > Why would you have so much trust in the ether unless you have met > someone with say a DNSSEC key or have a web of trust with someone you > have met and that you trust and has met and swapped keys further up > the line. The first key for DNSSEC is almost always untrusted, though > you can use SSL to check the fingerprint. Surely it takes more > resources for the NSA to get your particular CD? and surely you should > be prioritising other concerns than the NSA anyway and would see the > CD as a valuable extra authentication? Along the lines of what the > OpenBSD manual says, if the black suits target you, do you really > believe you can stop them? It is true that the first key of DNSSEC is always untrusted. But, there are plenty more ways to check it than the number OpenBSD mirrors. So the target is much bigger. I use every and any mean possible to validate things, DNSSEC would make things a little simpler, just it. I don't trust anything, not even myself. Humans have the tendency o fucking things up. The same for compromised machines. At least I can try to keep my machines not compromised. Unless some crazy scientist invents an injection that cures humans from making mistakes. I do not believe I can stop any government with loads of money from compromising my machines. But at the very least I can try to put up a hell of a fight for them. I do not like to be the low hanging fruit. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: signed packages
A huge swath of clean-up has just hit the trees. Most specifically, now that it works, the "signing-only" code has been moved into a separate "pkg_sign" command. This is partly for documentation purpose: it's much simpler to document the parameters to that command separately, instead of as additions to pkg_create(1) proper. pkg_create(1) still retains the ability to create signed packages on the fly, if people want to create their own signed packages (not recommanded for really paranoid people, since the build process can be "dirty"), but signing existing packages is really a mostly independent process (the only common part is signing packing-lists) so it makes more sense as a separate command.
Re: signed packages
previously on this list Giancarlo Razzolini contributed: I believe that with the interdiction > programs that NSA has, and maybe also other governments, CD's can not be > entitled with the same trust as before. Why would you have so much trust in the ether unless you have met someone with say a DNSSEC key or have a web of trust with someone you have met and that you trust and has met and swapped keys further up the line. The first key for DNSSEC is almost always untrusted, though you can use SSL to check the fingerprint. Surely it takes more resources for the NSA to get your particular CD? and surely you should be prioritising other concerns than the NSA anyway and would see the CD as a valuable extra authentication? Along the lines of what the OpenBSD manual says, if the black suits target you, do you really believe you can stop them? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
Re: signed packages
On 23/01/2014 12:52 AM, Bob Beck wrote: I think I'll make sure to advertise the next OpenBSD Foundation funding campaign by suggesting that you're not actually not real people, but a helpful-suggestions-posting-bot sponsored by the NSA.. Or maybe it's that they've infiltrated our educational systems... Please get our your tinfoil hats kids. OMG there's no replies.. The NSA programmed the 'bot to not respond to this topic! That's probably because the NSA are now so high on magic pixie dust from your previous post you sent them. When they come down the 'bot will respond. Ian McWilliam
Re: signed packages
We did print the whole blowfish implementation on the back of a t-shirt, and I can still read mine. So a key should not be a problem. :-) . Ken On 23 January 2014 09:13, Ted Unangst wrote: > On Wed, Jan 22, 2014 at 11:28, Stuart Henderson wrote: > > (IIRC somebody suggested printing keys on the tshirts, not sure if print > > resolution on fabric is really up to that without making the text so > > big as to be horribly ugly, posters may work though.) > > It's only 56 letters. 3 rows of 19 should fit pretty easily across the > bottom of a shirt in a font size (36) that's legible without dominating > the whole shirt. > >
Re: signed packages
On Wed, Jan 22, 2014 at 11:28, Stuart Henderson wrote: > (IIRC somebody suggested printing keys on the tshirts, not sure if print > resolution on fabric is really up to that without making the text so > big as to be horribly ugly, posters may work though.) It's only 56 letters. 3 rows of 19 should fit pretty easily across the bottom of a shirt in a font size (36) that's legible without dominating the whole shirt.
Re: signed packages
Em 22-01-2014 11:00, Bob Beck escreveu: > Our lists are so full of helpful smart people who think chains of > trust are magical pixie dust coming from root-provider-fairylands > where the root cert faires live in castles of uncompromising fortitude > that are never full of government plants and are whose certificates > are magically transported into operating systems and placed in that > special place in our hearts where no file could ever be modified... > They also suggest we should move the machines that generate the > releases into of those same castles where power is cheaper to save > money... > > I think I'll make sure to advertise the next OpenBSD Foundation > funding campaign by suggesting that you're not actually not real > people, but a helpful-suggestions-posting-bot sponsored by the NSA.. > Or maybe it's that they've infiltrated our educational systems... > Please get our your tinfoil hats kids. > Bob, There were lots of e-mails through the years on misc, some of myself, that asked for more, how can I say, "trustiness" on the getting the source and/or, just using the binaries provided by OpenBSD. I believe that signify helps a lot on this. I took a look at the code and it's simple and beautiful. I myself download the installXX.iso and source code from different mirrors/anoncvs, and using different internet links, just to be sure that things are in order. I'll be even more paranoid with the next release to make sure I have the right keys, both for 5.5 and the ones that follow. Tinfoil hats apart, I believe that with the interdiction programs that NSA has, and maybe also other governments, CD's can not be entitled with the same trust as before. I believe that DNSSEC is just one of the many things that could be done to make this "trust" more easy to obtain and verify. I've been living without it anyway. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: signed packages
previously on this list Jiri B contributed: > What about as TXT record for dns (in combination with DNSSEC) as alternative > for getting the key? :) The architecture for the root key handling (offline keys, multiple people etc.) is good obviously with bobs concerns though. I don't know much about signify yet except that it looks nicer than the old system and has been a nice surprise and certainly no nothing of the plans for it, however you have to verify the first root-anchor anyway for DNSSEC which can be done by anyone that builds and the anchor is signed but again requires a web of trust, so there's really no difference. Except that DNSSECs anchor is bundled with unbound already and then updates itself if you don't miss the window etc.. DNSSEC does offer some convenience for some things but not here I would suggest and unless it has moved to ECDSA already?, it isn't secure anyway with the 768bit RSA limit on TXT record size and also offers DOS and a potential of a 100x amplification to DDOS. I certainly have hopes for ECDSA DNSSEC coupled with other things (DNSCURVE, browser domain control validation) being used to sort out https with the only thing that counts (simple domain level trust) but I'm not full of confidence that it will when there is so much money to be made with the pointless (except PR) EV etc.. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
Re: signed packages
> I think I'll make sure to advertise the next OpenBSD Foundation > funding campaign by suggesting that you're not actually not real > people, but a helpful-suggestions-posting-bot sponsored by the NSA.. > Or maybe it's that they've infiltrated our educational systems... > Please get our your tinfoil hats kids. OMG there's no replies.. The NSA programmed the 'bot to not respond to this topic!
Re: signed packages
Our lists are so full of helpful smart people who think chains of
trust are magical pixie dust coming from root-provider-fairylands
where the root cert faires live in castles of uncompromising fortitude
that are never full of government plants and are whose certificates
are magically transported into operating systems and placed in that
special place in our hearts where no file could ever be modified...
They also suggest we should move the machines that generate the
releases into of those same castles where power is cheaper to save
money...
I think I'll make sure to advertise the next OpenBSD Foundation
funding campaign by suggesting that you're not actually not real
people, but a helpful-suggestions-posting-bot sponsored by the NSA..
Or maybe it's that they've infiltrated our educational systems...
Please get our your tinfoil hats kids.
On Wed, Jan 22, 2014 at 5:39 AM, Bob Beck wrote:
> Yeah. Ok mister chicken before egg.. We should validate this thing shipped
> in a release using dnssec with a root of trust depending on root certs
> shipped with the release...Love that idea.. But maybe I'll just buy a
> CD.
>
> On 22 Jan 2014 05:13, "Jiri B" wrote:
>>
>> On Wed, Jan 22, 2014 at 11:28:50AM +, Stuart Henderson wrote:
>> > The model is: only the specific keys placed in /etc/signify are trusted.
>> >
>> > The plan is to include the public keys used for signing release n+1 in
>> > release n. So once you trust a particular key, by verifying signatures
>> > on sets which you download+install, you can have a chain of continuity
>> > for future keys.
>> >
>> > You still need to get your initial key from somewhere that you
>> > trust. If you are worried about sources of this, you can at least
>> > check and compare the 55*.pub files from a few sources e.g. those in
>> > downloaded sets against those in anoncvs/cvsweb ("cvs -d $CVSROOT get
>> > -p src/etc/signify/55base.pub" to display on stdout). Of course when
>> > the next release is done they'll be on CD.
>> >
>> > (IIRC somebody suggested printing keys on the tshirts, not sure if print
>> > resolution on fabric is really up to that without making the text so
>> > big as to be horribly ugly, posters may work though.)
>> >
>> > Given sufficient space to download tgz before unpacking, the install
>> > ramdisk kernel now checks signatures (yes: crypto fits on the ramdisk
>> > - signify/ed25519 is small, and yes: please test and report on any
>> > problems!).
>> >
>> > If you're fetching a new installer (ramdisk kernel, install55.iso,
>> > floppy*.fs, etc) you can verify the signature of that file before using
>> > it. Also it should go without saying, if you use the "untar sets on a
>> > running system" method, checking those sets is your responsibility,
>> > see signify(1)'s EXAMPLES section for information about how to do this.
>>
>> What about as TXT record for dns (in combination with DNSSEC) as
>> alternative
>> for getting the key? :)
>>
>> jirib
>>
>
Re: signed packages
Yeah. Ok mister chicken before egg.. We should validate this thing
shipped in a release using dnssec with a root of trust depending on root
certs shipped with the release...Love that idea.. But maybe I'll just
buy a CD.
On 22 Jan 2014 05:13, "Jiri B" wrote:
> On Wed, Jan 22, 2014 at 11:28:50AM +, Stuart Henderson wrote:
> > The model is: only the specific keys placed in /etc/signify are trusted.
> >
> > The plan is to include the public keys used for signing release n+1 in
> > release n. So once you trust a particular key, by verifying signatures
> > on sets which you download+install, you can have a chain of continuity
> > for future keys.
> >
> > You still need to get your initial key from somewhere that you
> > trust. If you are worried about sources of this, you can at least
> > check and compare the 55*.pub files from a few sources e.g. those in
> > downloaded sets against those in anoncvs/cvsweb ("cvs -d $CVSROOT get
> > -p src/etc/signify/55base.pub" to display on stdout). Of course when
> > the next release is done they'll be on CD.
> >
> > (IIRC somebody suggested printing keys on the tshirts, not sure if print
> > resolution on fabric is really up to that without making the text so
> > big as to be horribly ugly, posters may work though.)
> >
> > Given sufficient space to download tgz before unpacking, the install
> > ramdisk kernel now checks signatures (yes: crypto fits on the ramdisk
> > - signify/ed25519 is small, and yes: please test and report on any
> > problems!).
> >
> > If you're fetching a new installer (ramdisk kernel, install55.iso,
> > floppy*.fs, etc) you can verify the signature of that file before using
> > it. Also it should go without saying, if you use the "untar sets on a
> > running system" method, checking those sets is your responsibility,
> > see signify(1)'s EXAMPLES section for information about how to do this.
>
> What about as TXT record for dns (in combination with DNSSEC) as
> alternative
> for getting the key? :)
>
> jirib
>
>
Re: signed packages
On Wed, Jan 22, 2014 at 11:28:50AM +, Stuart Henderson wrote:
> The model is: only the specific keys placed in /etc/signify are trusted.
>
> The plan is to include the public keys used for signing release n+1 in
> release n. So once you trust a particular key, by verifying signatures
> on sets which you download+install, you can have a chain of continuity
> for future keys.
>
> You still need to get your initial key from somewhere that you
> trust. If you are worried about sources of this, you can at least
> check and compare the 55*.pub files from a few sources e.g. those in
> downloaded sets against those in anoncvs/cvsweb ("cvs -d $CVSROOT get
> -p src/etc/signify/55base.pub" to display on stdout). Of course when
> the next release is done they'll be on CD.
>
> (IIRC somebody suggested printing keys on the tshirts, not sure if print
> resolution on fabric is really up to that without making the text so
> big as to be horribly ugly, posters may work though.)
>
> Given sufficient space to download tgz before unpacking, the install
> ramdisk kernel now checks signatures (yes: crypto fits on the ramdisk
> - signify/ed25519 is small, and yes: please test and report on any
> problems!).
>
> If you're fetching a new installer (ramdisk kernel, install55.iso,
> floppy*.fs, etc) you can verify the signature of that file before using
> it. Also it should go without saying, if you use the "untar sets on a
> running system" method, checking those sets is your responsibility,
> see signify(1)'s EXAMPLES section for information about how to do this.
What about as TXT record for dns (in combination with DNSSEC) as alternative
for getting the key? :)
jirib
Re: signed packages
On 2014/01/22 13:46, Loganaden Velvindron wrote:
> On Fri, Jan 17, 2014 at 3:26 PM, Marc Espie wrote:
> > It's probably time to talk about it.
> >
> > Yes, we are now distributing signed packages. A lot of people have probably
> > noticed because there was a key mismatch on at least one batch of signed
> > packages.
> >
> > Obviously, we haven't finished testing yet.
> >
> > Don't read too much into that. "Signed packages" just mean you can use
> > an insecure medium, such as ftp, to download packages: if the key matches,
> > it means the package hasn't been tampered with since it was signed.
> >
> > The cryptographic framework used to sign packages is called signify(1),
> > mostly written by Ted Unangst, with a lot of feedback from (mostly) Theo
> > and I.
> >
> > The signing framework in pkg_add/pkg_create is much older than that, if
> > was written for x509 a few years ago, but signify(1) will probably be more
> > robust and ways simpler. In particular, there's no "chain-of-trust", so
> > you keep complete control on the sources YOU trust.
>
> Can you please elborate more on the trusting part ?
>
> Both DNSSEC and RPKI have a "root anchor" that we're all supposed to trust,
> and your model is different.
The model is: only the specific keys placed in /etc/signify are trusted.
The plan is to include the public keys used for signing release n+1 in
release n. So once you trust a particular key, by verifying signatures
on sets which you download+install, you can have a chain of continuity
for future keys.
You still need to get your initial key from somewhere that you
trust. If you are worried about sources of this, you can at least
check and compare the 55*.pub files from a few sources e.g. those in
downloaded sets against those in anoncvs/cvsweb ("cvs -d $CVSROOT get
-p src/etc/signify/55base.pub" to display on stdout). Of course when
the next release is done they'll be on CD.
(IIRC somebody suggested printing keys on the tshirts, not sure if print
resolution on fabric is really up to that without making the text so
big as to be horribly ugly, posters may work though.)
Given sufficient space to download tgz before unpacking, the install
ramdisk kernel now checks signatures (yes: crypto fits on the ramdisk
- signify/ed25519 is small, and yes: please test and report on any
problems!).
If you're fetching a new installer (ramdisk kernel, install55.iso,
floppy*.fs, etc) you can verify the signature of that file before using
it. Also it should go without saying, if you use the "untar sets on a
running system" method, checking those sets is your responsibility,
see signify(1)'s EXAMPLES section for information about how to do this.
Re: signed packages
On Wed, Jan 22, 2014 at 01:46:33PM +0400, Loganaden Velvindron wrote: > > The signing framework in pkg_add/pkg_create is much older than that, if > > was written for x509 a few years ago, but signify(1) will probably be more > > robust and ways simpler. In particular, there's no "chain-of-trust", so > > you keep complete control on the sources YOU trust. > > Can you please elborate more on the trusting part ? > > Both DNSSEC and RPKI have a "root anchor" that we're all supposed to trust, > and your model is different. There's no chain of trust. pkg_add trusts pub keys under /etc/signify that end in *pkg.pub (respectively *fw.pub for firmwares). Put shit there -> get shit out. the only way to get keys in there is: - base install, - explicitly putting keys there as root. There's nothing more automated. Keys are not certified nor anything.
Re: signed packages
On Fri, Jan 17, 2014 at 3:26 PM, Marc Espie wrote: > It's probably time to talk about it. > > Yes, we are now distributing signed packages. A lot of people have probably > noticed because there was a key mismatch on at least one batch of signed > packages. > > Obviously, we haven't finished testing yet. > > Don't read too much into that. "Signed packages" just mean you can use > an insecure medium, such as ftp, to download packages: if the key matches, > it means the package hasn't been tampered with since it was signed. > > The cryptographic framework used to sign packages is called signify(1), > mostly written by Ted Unangst, with a lot of feedback from (mostly) Theo > and I. > > The signing framework in pkg_add/pkg_create is much older than that, if > was written for x509 a few years ago, but signify(1) will probably be more > robust and ways simpler. In particular, there's no "chain-of-trust", so > you keep complete control on the sources YOU trust. Can you please elborate more on the trusting part ? Both DNSSEC and RPKI have a "root anchor" that we're all supposed to trust, and your model is different. > > Signatures should be transparent in use: the package is opened, the > packing-list signature is checked, and then files are checksummed while > extracted against the packing-list embedded checksums (there are provisions > to ensure any dangerous meta-data is also encoded in the packing-list as > @mode/@user/@group annotations. > > So, barring problems, you shouldn't even notice signatures. > -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
Re: signed packages
On Fri, Jan 17, 2014 at 12:39:49PM -0500, sven falempin wrote:
> i read the manuals , and well , i am still unsure,
>
> if i put SIGNER=bob in the package configuration
>
> then it will be signed with
>
> /etc/signify/bob.sec
>
> having to read 4 different manual page to get this is strange :p
No, that part got simpler.
Keys are currently under /etc/signify
They *must* be there for the public keys.
Keys for signed packages should match *pkg.sec / *pkg.pub
(distinguished by function: firmware keys end in fw.sec / fw.pub)
Read signify(1) to generate the keys.
Say:
signify -G -n -s sven-pkg.sec -p sven-pkg.pub
For signing while building, just set
SIGNING_PARAMETERS = -s signify -s /etc/signify/sven-pkg.sec
for signing after building, do something like:
cd /usr/ports/packages/${ARCH}
mkdir signed
pkg_create -j4 -v -s signify -s /etc/signify/sven-pkg.sec -o signed -S all
That's all there is to it. If both the pubkey and privkey are present, the
first signed package written out will be checked (signify keys don't
carry any identity, they just have a fingerprint, so key mismatches are
easy to create if you're not careful -> the signed package carries a
@signer sven-pkg annotation to select the correct key).
pkg_add will trust keys under /etc/signify that match *pkg.pub
If you really want to trust a specific key *only*,
pkg_add -DSIGNER=sven-pkg ...
If some booboo happened, pkg_add -Dnosig will not check sigs at all...
Re: signed packages
On Fri, Jan 17, 2014 at 12:28 PM, Marc Espie wrote: > > On Fri, Jan 17, 2014 at 06:23:53PM +0100, Marc Espie wrote: > > On Fri, Jan 17, 2014 at 12:09:31PM -0500, sven falempin wrote: > > > > > >Awesome. > > >Â * the one on the client openBSD > > >Â * the one on the builder > > >is there a new make command in ports to sign ? like make sign ? make > > >resign ? > > > > See signify(1), pkg_add(1), pkg_create(1), bsd.port.mk(5) (look for > > SIGNING_PARAMETERS). > > > > Packages can be signed during build, or later. > > There's no new command, pkg_create(1) is used for creating signed packages. > > Note that things are still WILDLY changing. I assume that by now, > lots of people have noticed the signed stuff. This is still a moving > target (working quite well IMO). i read the manuals , and well , i am still unsure, if i put SIGNER=bob in the package configuration then it will be signed with /etc/signify/bob.sec having to read 4 different manual page to get this is strange :p -- - () ascii ribbon campaign - against html e-mail /\
Re: signed packages
On Fri, Jan 17, 2014 at 06:23:53PM +0100, Marc Espie wrote: > On Fri, Jan 17, 2014 at 12:09:31PM -0500, sven falempin wrote: > > > >Awesome. > >Â * the one on the client openBSD > >Â * the one on the builder > >is there a new make command in ports to sign ? like make sign ? make > >resign ? > > See signify(1), pkg_add(1), pkg_create(1), bsd.port.mk(5) (look for > SIGNING_PARAMETERS). > > Packages can be signed during build, or later. > There's no new command, pkg_create(1) is used for creating signed packages. Note that things are still WILDLY changing. I assume that by now, lots of people have noticed the signed stuff. This is still a moving target (working quite well IMO).
Re: signed packages
On Fri, Jan 17, 2014 at 12:09:31PM -0500, sven falempin wrote: > >Awesome. >Â * the one on the client openBSD >Â * the one on the builder >is there a new make command in ports to sign ? like make sign ? make >resign ? See signify(1), pkg_add(1), pkg_create(1), bsd.port.mk(5) (look for SIGNING_PARAMETERS). Packages can be signed during build, or later. There's no new command, pkg_create(1) is used for creating signed packages.
Re: signed packages
Awesome. To keep OUR control, one shall create a FTP, resign all packet and update the key, or generate packet and sign with is own key, moreover update the one on his openBSD client , where are those keys ? * the one on the client openBSD * the one on the builder is there a new make command in ports to sign ? like make sign ? make resign ? + On Fri, Jan 17, 2014 at 6:26 AM, Marc Espie wrote: > It's probably time to talk about it. > > Yes, we are now distributing signed packages. A lot of people have > probably > noticed because there was a key mismatch on at least one batch of signed > packages. > > Obviously, we haven't finished testing yet. > > Don't read too much into that. "Signed packages" just mean you can use > an insecure medium, such as ftp, to download packages: if the key matches, > it means the package hasn't been tampered with since it was signed. > > The cryptographic framework used to sign packages is called signify(1), > mostly written by Ted Unangst, with a lot of feedback from (mostly) Theo > and I. > > The signing framework in pkg_add/pkg_create is much older than that, if > was written for x509 a few years ago, but signify(1) will probably be more > robust and ways simpler. In particular, there's no "chain-of-trust", so > you keep complete control on the sources YOU trust. > > Signatures should be transparent in use: the package is opened, the > packing-list signature is checked, and then files are checksummed while > extracted against the packing-list embedded checksums (there are provisions > to ensure any dangerous meta-data is also encoded in the packing-list as > @mode/@user/@group annotations. > > So, barring problems, you shouldn't even notice signatures. > > -- - () ascii ribbon campaign - against html e-mail /\
Re: pkg_add (pkg.conf): option to require signed packages
On Fri, Jan 17, 2014 at 09:59:03AM +0100, Sébastien Marie wrote: > On Thu, Jan 16, 2014 at 10:02:22AM +, Stuart Henderson wrote: > > On 2014/01/16 08:53, Sébastien Marie wrote: > > > Hi, > > > > > > Does it make sens to have an option to require package to be signed ? > > > > It makes more sense to just enable that by default, when we are happy > > with the infrastructure and usage. > > > > I saw "enable by default" more as long term purpose. The patch would > permit to easily test it... Enable by default is trivial to do. Look around the code that says "check_signature" in OpenBSD/PkgAdd.pm, I'm sure you can figure out the change.
signed packages
It's probably time to talk about it. Yes, we are now distributing signed packages. A lot of people have probably noticed because there was a key mismatch on at least one batch of signed packages. Obviously, we haven't finished testing yet. Don't read too much into that. "Signed packages" just mean you can use an insecure medium, such as ftp, to download packages: if the key matches, it means the package hasn't been tampered with since it was signed. The cryptographic framework used to sign packages is called signify(1), mostly written by Ted Unangst, with a lot of feedback from (mostly) Theo and I. The signing framework in pkg_add/pkg_create is much older than that, if was written for x509 a few years ago, but signify(1) will probably be more robust and ways simpler. In particular, there's no "chain-of-trust", so you keep complete control on the sources YOU trust. Signatures should be transparent in use: the package is opened, the packing-list signature is checked, and then files are checksummed while extracted against the packing-list embedded checksums (there are provisions to ensure any dangerous meta-data is also encoded in the packing-list as @mode/@user/@group annotations. So, barring problems, you shouldn't even notice signatures.
Re: pkg_add (pkg.conf): option to require signed packages
On Thu, Jan 16, 2014 at 10:02:22AM +, Stuart Henderson wrote: > On 2014/01/16 08:53, Sébastien Marie wrote: > > Hi, > > > > Does it make sens to have an option to require package to be signed ? > > It makes more sense to just enable that by default, when we are happy > with the infrastructure and usage. > I saw "enable by default" more as long term purpose. The patch would permit to easily test it... But I am confident about your choices. Thanks. -- Sébastien Marie
Re: pkg_add (pkg.conf): option to require signed packages
On 2014/01/16 08:53, Sébastien Marie wrote: > Hi, > > Does it make sens to have an option to require package to be signed ? It makes more sense to just enable that by default, when we are happy with the infrastructure and usage.
pkg_add (pkg.conf): option to require signed packages
Hi,
Does it make sens to have an option to require package to be signed ?
Currently, a package without signature is gracefully installed without
warning.
The patch introduce an option "require-signature" in pkg.conf, and it
respects -Dnosig in comand-line, if present.
Thanks.
--
Sébastien Marie
Index: pkg.conf.5
===
RCS file: /cvs/src/usr.sbin/pkg_add/pkg.conf.5,v
retrieving revision 1.5
diff -u -p -r1.5 pkg.conf.5
--- pkg.conf.5 11 Oct 2012 17:35:45 - 1.5
+++ pkg.conf.5 16 Jan 2014 07:47:30 -
@@ -78,6 +78,10 @@ to waive checksums during package deleti
Set to
.Ar yes
to display (done/total) number of package messages.
+.It Ar require-signature
+Set to
+.Ar yes
+to require packages to be signed.
.El
.Pp
Each option uses a separate line, and follows the following template:
Index: OpenBSD/PkgAdd.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PkgAdd.pm,v
retrieving revision 1.45
diff -u -p -r1.45 PkgAdd.pm
--- OpenBSD/PkgAdd.pm 11 Jan 2014 11:54:43 - 1.45
+++ OpenBSD/PkgAdd.pm 16 Jan 2014 07:47:30 -
@@ -663,6 +663,9 @@ sub check_digital_signature
$state->{check_digest} = 1;
$state->{packages_with_sig}++;
}
+ } elsif ($state->config->istrue("require-signature") and !
$state->defines('nosig')) {
+ $state->fatal("#1 isn't signed and signature is
required",
+ $plist->pkgname);
} else {
$state->{packages_without_sig}{$plist->pkgname} = 1;
}
