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 pr
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 s
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 alm
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 e
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 D
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 sy
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 o
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
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
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 abou
> 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 tinf
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 in
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
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
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 m
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",
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.
>
> Obvi
e 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 k
ages 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
> tar
s 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 pa
(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.
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 a
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 se
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. "S
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
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.
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 Mari
27 matches
Mail list logo
