signed packages

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

signed packages

Marc Espie-2
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.

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

sven falempin
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 <public> one on the client openBSD
 * the <private> 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 <[hidden email]> 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
/\
Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Marc Espie-2
On Fri, Jan 17, 2014 at 12:09:31PM -0500, sven falempin wrote:
>
>    Awesome.
>    Â * the <public> one on the client openBSD
>    Â * the <private> 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.

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Marc Espie-2
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 <public> one on the client openBSD
> >    Â * the <private> 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).

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

sven falempin
On Fri, Jan 17, 2014 at 12:28 PM, Marc Espie <[hidden email]> 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 <public> one on the client openBSD
> > >    Â * the <private> 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
/\
Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Marc Espie-2
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...

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Loganaden Velvindron-2
In reply to this post by Marc Espie-2
On Fri, Jan 17, 2014 at 3:26 PM, Marc Espie <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Marc Espie-2
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.

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Stuart Henderson-6
In reply to this post by Loganaden Velvindron-2
On 2014/01/22 13:46, Loganaden Velvindron wrote:

> On Fri, Jan 17, 2014 at 3:26 PM, Marc Espie <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Jiri B-2
On Wed, Jan 22, 2014 at 11:28:50AM +0000, 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

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Bob Beck-2
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" <[hidden email]> wrote:

> On Wed, Jan 22, 2014 at 11:28:50AM +0000, 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Bob Beck-2
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 <[hidden email]> 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" <[hidden email]> wrote:
>>
>> On Wed, Jan 22, 2014 at 11:28:50AM +0000, 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
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Bob Beck-2
> 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!

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Kevin Chadwick-2
In reply to this post by Jiri B-2
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
_______________________________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Giancarlo Razzolini-3
In reply to this post by Bob Beck-2
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

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Ted Unangst-6
In reply to this post by Marc Espie-2
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.

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

kwesterback
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 <[hidden email]> 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.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Ian McWilliam-2
In reply to this post by Bob Beck-2
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

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Kevin Chadwick-2
In reply to this post by Giancarlo Razzolini-3
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
_______________________________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: signed packages

Marc Espie-2
In reply to this post by Marc Espie-2
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.

12