Code signing in OpenBSD

[Gilbert Fernandes-4]

On Thu, Dec 06, 2007 at 09:08:56AM -0600, Marco Peereboom wrote:

> hitler already

Here is yours :

+----------------+
| 1 Godwin point |
+----------------+

Bye

--
unzip ; strip ; touch ; grep ; find ; finger ; mount ; fsck ; more ;
yes ; fsck ; umount ; sleep

[Eric Furman-3]

On Thu, 6 Dec 2007 09:51:16 -0500, "Douglas A. Tutty"
<dtutty@...> said:
> Personally, if this thread is to continue, I would like to see it move
> from a "Why doesn't OpenBSD do things this way?" to a "What are the
> threat models for OpenBSD identity theft and how can we protect
> ourselves?".

Please don't. I am getting tired of deleting this stupid thread.
The project has been around for more than ten years.
Do you think the devs are so completely clueless about
security that they haven't already thought about this?
Actually, a couple of the devs have already spoken up
on this topic and gave you the answer so please shut up already.
Sorry for adding to the talk talk talking, but people like Theo
actually read all this crap and it's wasting their time.

[Jason George]

>> > Come on... twice a year and get the benefit of not being excluded from
>> > company policies which require digital signature of software downloaded
>> > through the internet.
>>
>> It's not really OpenBSD's problem that some companies implement pointless
>> "security" policies.
>
>I'm not discussing wether its pointless or not, maybe you don't want
>OpenBSD to be used at all?

You make it sound like OpenBSD is a vendor that is actively marketing to these
companies and that cannot make a sale because it is not meeting a specific set
of criteria in your requirements docs.

Tell you what.  I am sure there are a number of individuals on the list who
own or work at companies that would be more than happy to provide your
employer with a custom-built set of installation binaries and packages, signed
for your digital pleasure.  I expect bi-annual costs, including overhead like
lawyers, errors and omissions insurance, etc, to run mid-5-figures per
release.  Minimum 5 release contract.  Expect much re-writing of contract
clauses.  If there is indeed that much value derived in your organization from
the use of OpenBSD, then this will be a paltry sum to pay.

I am fairly confident that Oracle and Sun and SAP likely aren't PKI'ing their
updates from their websites.  Oh wait.  Are those excluded from the company
policy because you have a contract in place?  

I went through a similar policy a few years ago while doing Sarbanes-Oxley
consulting.  The lawyers and auditors were screaming for validation of free
software, like Perl.  After many months of having tantrums, they, along with
management, finally realized that going down this path would be tantamount to
try to chip away all the morter keeping a brick building together.  The
effects on the integrity of the structure (corporate, in this case) would be
too great to keep pursuing this line of thought.  That policy was abandoned
because it was costing more to implement than the perceived risks they
believed they could mitigate. (i.e. - they had to think in practical terms)

Shortly afterward, I went back to steel-toed-boots engineering, where risks
models really matter because you're trying to ensure that people don't get
killed, that the environment doesn't get polluted, that you don't destroy
assets and that you don't impact production.  Digital signatures are pretty
irrelevant when you need to be concerned about an explosion that could
potentially wipe out a few hundred million in infrastructure in the space of a
few city blocks.  Or when an H2S leak can kill you and your crew in the matter
of a few breaths.

If it's that important, shut up and hack.  Or otherwise just shut up.

[Jeff I. Ragland]

On 06 NN5N: 2007, at 5:39 NN, bofh wrote:

> You forgot one option.  Invite Theo to give a talk, and ask him to
> bring the CDs.  If you can't trust Theo's CDs, all hope is lost.

And how would you know that it is indeed Theo and not someone that
looks like him? I think that blood samples and DNA tests is the only
way to go here.

>
>
> Just need to make sure there're some mountains around for Theo to go
> climb.  If you live on a flatland, then, sorry, you're doomed.
>
>
> On 12/6/07, Douglas A. Tutty <dtutty@...> wrote:
>> On Thu, Dec 06, 2007 at 11:48:55AM +0100, Hannah Schroeter wrote:
>>
>>> One risk would be the plans of "online surveillance" of computers
>>> e.g.
>>> in Germany. One way to install surveillance even on OpenBSD would
>>> be to
>>> actively interfere with the internet connection with the surveilled
>>> person, in the man-in-the-middle sense, and inject trojanned code
>>> ("Bundestrojaner") into the updates of the victim.
>>
>> Using software from any source without interference from an
>> all-pervasive government is a very special, but unfortunatly today, a
>> very real issue for many people around the world.  To be secure, you
>> have to get pieces of the puzzle over multiple paths.  It all can't
>> come
>> via the net since then you're open to man-in-the-middle.
>>
>> Key-revocation announcements could come over the net (via an announce
>> list) but the new key would then have to come over a second channel.
>>
>> One second-channel option is the q6mth CD issue, which could
>> include a
>> new public key and e.g. known-hosts fingerprints.  This is
>> vulnerable to
>> a very determined man-in-the-middle who can replicate and then
>> alter the
>> CD before it arrives to you in the mail.
>>
>> Another option is a trusted courier flying to Alberta and get a CD
>> from
>> the OpenBSD store  (yeah, right).
>>
>> In fact, likely any other technological option (e.g. an answering
>> machine in Alberta that spits out the alphanumerics of the current
>> master public key) is still suceptible.
>>
>> If every piece of information you receive is filter through your
>> government, is there any hand-shaking protocol that can allow you to
>> establish a verified information connection (not necessarily
>> encrypted)?
>> I don't think so.
>>
>> Sure, Debian has signed .debs that use gpg as a back end (the
>> system is
>> called apt-key), it relies on you trusting the fist key that you get
>> from them.  Since Debian doesn't actually mail out its own CDs,
>> everything is off its mirrors.  apt-key only 'protects' you from a
>> later
>> man-in-the-middle.
>>
>> I think that this is the central 'problem' that people are dancing
>> around.
>>
>> Personally, if this thread is to continue, I would like to see it
>> move
>> from a "Why doesn't OpenBSD do things this way?" to a "What are the
>> threat models for OpenBSD identity theft and how can we protect
>> ourselves?".
>>
>> Doug.
>>
>>
>
>
> --
> http://www.glumbert.com/media/shift
> http://www.youtube.com/watch?v=tGvHNNOLnCk
> "This officer's men seem to follow him merely out of idle curiosity."
> -- Sandhurst officer cadet evaluation.
> "Securing an environment of Windows platforms from abuse - external or
> internal - is akin to trying to install sprinklers in a fireworks
> factory where smoking on the job is permitted."  -- Gene Spafford

[BOFH-5]

Code signing by blood.  ISAGN.


"Sorry marc - had to do it"


On 12/6/07, Jeff I. Ragland <jeff.i.ragland@...> wrote:

>
> On 06 Dej 2007, at 5:39 LL, bofh wrote:
>
> > You forgot one option.  Invite Theo to give a talk, and ask him to
> > bring the CDs.  If you can't trust Theo's CDs, all hope is lost.
>
> And how would you know that it is indeed Theo and not someone that
> looks like him? I think that blood samples and DNA tests is the only
> way to go here.
>
>
> >
> >
> > Just need to make sure there're some mountains around for Theo to go
> > climb.  If you live on a flatland, then, sorry, you're doomed.
> >
> >
> > On 12/6/07, Douglas A. Tutty <dtutty@...> wrote:
> >> On Thu, Dec 06, 2007 at 11:48:55AM +0100, Hannah Schroeter wrote:
> >>
> >>> One risk would be the plans of "online surveillance" of computers
> >>> e.g.
> >>> in Germany. One way to install surveillance even on OpenBSD would
> >>> be to
> >>> actively interfere with the internet connection with the surveilled
> >>> person, in the man-in-the-middle sense, and inject trojanned code
> >>> ("Bundestrojaner") into the updates of the victim.
> >>
> >> Using software from any source without interference from an
> >> all-pervasive government is a very special, but unfortunatly today, a
> >> very real issue for many people around the world.  To be secure, you
> >> have to get pieces of the puzzle over multiple paths.  It all can't
> >> come
> >> via the net since then you're open to man-in-the-middle.
> >>
> >> Key-revocation announcements could come over the net (via an announce
> >> list) but the new key would then have to come over a second channel.
> >>
> >> One second-channel option is the q6mth CD issue, which could
> >> include a
> >> new public key and e.g. known-hosts fingerprints.  This is
> >> vulnerable to
> >> a very determined man-in-the-middle who can replicate and then
> >> alter the
> >> CD before it arrives to you in the mail.
> >>
> >> Another option is a trusted courier flying to Alberta and get a CD
> >> from
> >> the OpenBSD store  (yeah, right).
> >>
> >> In fact, likely any other technological option (e.g. an answering
> >> machine in Alberta that spits out the alphanumerics of the current
> >> master public key) is still suceptible.
> >>
> >> If every piece of information you receive is filter through your
> >> government, is there any hand-shaking protocol that can allow you to
> >> establish a verified information connection (not necessarily
> >> encrypted)?
> >> I don't think so.
> >>
> >> Sure, Debian has signed .debs that use gpg as a back end (the
> >> system is
> >> called apt-key), it relies on you trusting the fist key that you get
> >> from them.  Since Debian doesn't actually mail out its own CDs,
> >> everything is off its mirrors.  apt-key only 'protects' you from a
> >> later
> >> man-in-the-middle.
> >>
> >> I think that this is the central 'problem' that people are dancing
> >> around.
> >>
> >> Personally, if this thread is to continue, I would like to see it
> >> move
> >> from a "Why doesn't OpenBSD do things this way?" to a "What are the
> >> threat models for OpenBSD identity theft and how can we protect
> >> ourselves?".
> >>
> >> Doug.
> >>
> >>
> >
> >
> > --
> > http://www.glumbert.com/media/shift
> > http://www.youtube.com/watch?v=tGvHNNOLnCk
> > "This officer's men seem to follow him merely out of idle curiosity."
> > -- Sandhurst officer cadet evaluation.
> > "Securing an environment of Windows platforms from abuse - external or
> > internal - is akin to trying to install sprinklers in a fireworks
> > factory where smoking on the job is permitted."  -- Gene Spafford
> >
>
>

--
http://www.glumbert.com/media/shift
http://www.youtube.com/watch?v=tGvHNNOLnCk
"This officer's men seem to follow him merely out of idle curiosity."
-- Sandhurst officer cadet evaluation.
"Securing an environment of Windows platforms from abuse - external or
internal - is akin to trying to install sprinklers in a fireworks
factory where smoking on the job is permitted."  -- Gene Spafford

[Douglas A. Tutty]

On Thu, Dec 06, 2007 at 05:24:40PM +0200, Lars Nood??n wrote:
> Douglas A. Tutty wrote:
> > Using software from any source without interference from an
> > all-pervasive government is a very special,...
>
> It's not all about governments.  Corporate espionage is probably a
> larger, more active threat, especially to OpenBSD.

True, but a single source of corporate espionage can't attack the mail,
phone, fax, and internet (e.g. ftp) all at the same time.

>
> "cui bono?"
>
> If we assume for the sake of argument that the printed CDs are ok, then
> there is at least one method for distributing keys and/or building a web
> of trust.
>
> -Lars
>
Doug.

[Douglas A. Tutty]

On Thu, Dec 06, 2007 at 09:39:35AM -0600, bofh wrote:
> You forgot one option.  Invite Theo to give a talk, and ask him to
> bring the CDs.  If you can't trust Theo's CDs, all hope is lost.

He doesn't have to bring the CDs, just in the speach give the MD5 (or
other more secure [sha?} sum for an .iso file made from those CDs.  Buy
the CD, create an image, calc the md5.  Compare with Theo's speach.

Doug.

[Daniel Bosk]

>Hi!
>
>On Thu, Dec 06, 2007 at 11:23:37AM +0000, Stuart Henderson wrote:
>>On 2007/12/06 13:12, Lars Noodin wrote:
>
>>> If the installation process (from the purchased CDs) had a list of the
>>> public keys for the official mirror sites, then that would go a long
>>> way.
>
>>That would make it rather hard to revoke a key if there ever
>>was a problem.
>
>Key revocation lists in some form? If it's gpg/OpenPGP, instruct users
>to update from keyservers, one will notice when there're
>incompatibilities between the key from CD and the one from the
>keyserver, but one will also get the revocation from the keyserver. And
>if one buys every CD, there's the time window of half a year even
>without a key revocation infrastructure.
>
>Kind regards,
>
>Hannah.

Why not start selling public key lists from the order site, then
those who care can order one (or more) CD(s) and a separately
delivered (set of) public key lists (in sealed envelopes). Otherwise
ordering CDs will suffice.

When a key is revoked (announced somewhere) or incompatibilities
occur order a new (set of) list(s).

Then there is the problem of the lists being replaced by some new
list by the postman, thus ordering a set of lists instead of only one.
Have them delivered by different couriers, if all of them replaces the
list you will probably know.

Now, that will require a lot of work, and a lot of money (a lot of fuss
for a piece of paper) to scare most people off. Problem solved.

Brad, you really did start some thread. Starting with a rather
innocent question. Interesting reading though.


My best to all of you,

  Daniel

[Jacob Yocom-Piatt-2]

bofh wrote:
> Code signing by blood.  ISAGN.
>
>
> "Sorry marc - had to do it"
>
>  


what if theo is a "person of interest", has his endpoint surveilled and
his key and passphrase are compromised? if somebody stole a pint of
blood, that could go a long way in your proposed plan...

short of having a web of trust, meeting people in person to sign their
keys and assuming private keys and passphrases have not been
compromised, you're pretty much SOL here. best bet is to use anoncvs and
verify your cvs server's public key in person, but even that is a PITA.
if massive databases of key fingerprint collisions exist MITM is very
real even with a key fingerprint, multiple fingerprints make this much
harder.

if anyone has a non-trivial quantum computer or remote viewing really
works, the gig is pretty much up anyhow.

< jy-p cinches his tinfoil hat and returns to following the yellow brick
road... >

> On 12/6/07, Jeff I. Ragland <jeff.i.ragland@...> wrote:
>  
>> On 06 Dej 2007, at 5:39 LL, bofh wrote:
>>
>>    
>>> You forgot one option.  Invite Theo to give a talk, and ask him to
>>> bring the CDs.  If you can't trust Theo's CDs, all hope is lost.
>>>      
>> And how would you know that it is indeed Theo and not someone that
>> looks like him? I think that blood samples and DNA tests is the only
>> way to go here.
>>
>>
>>    
>>> Just need to make sure there're some mountains around for Theo to go
>>> climb.  If you live on a flatland, then, sorry, you're doomed.
>>>
>>>
>>> On 12/6/07, Douglas A. Tutty <dtutty@...> wrote:
>>>      
>>>> On Thu, Dec 06, 2007 at 11:48:55AM +0100, Hannah Schroeter wrote:
>>>>
>>>>        
>>>>> One risk would be the plans of "online surveillance" of computers
>>>>> e.g.
>>>>> in Germany. One way to install surveillance even on OpenBSD would
>>>>> be to
>>>>> actively interfere with the internet connection with the surveilled
>>>>> person, in the man-in-the-middle sense, and inject trojanned code
>>>>> ("Bundestrojaner") into the updates of the victim.
>>>>>          
>>>> Using software from any source without interference from an
>>>> all-pervasive government is a very special, but unfortunatly today, a
>>>> very real issue for many people around the world.  To be secure, you
>>>> have to get pieces of the puzzle over multiple paths.  It all can't
>>>> come
>>>> via the net since then you're open to man-in-the-middle.
>>>>
>>>> Key-revocation announcements could come over the net (via an announce
>>>> list) but the new key would then have to come over a second channel.
>>>>
>>>> One second-channel option is the q6mth CD issue, which could
>>>> include a
>>>> new public key and e.g. known-hosts fingerprints.  This is
>>>> vulnerable to
>>>> a very determined man-in-the-middle who can replicate and then
>>>> alter the
>>>> CD before it arrives to you in the mail.
>>>>
>>>> Another option is a trusted courier flying to Alberta and get a CD
>>>> from
>>>> the OpenBSD store  (yeah, right).
>>>>
>>>> In fact, likely any other technological option (e.g. an answering
>>>> machine in Alberta that spits out the alphanumerics of the current
>>>> master public key) is still suceptible.
>>>>
>>>> If every piece of information you receive is filter through your
>>>> government, is there any hand-shaking protocol that can allow you to
>>>> establish a verified information connection (not necessarily
>>>> encrypted)?
>>>> I don't think so.
>>>>
>>>> Sure, Debian has signed .debs that use gpg as a back end (the
>>>> system is
>>>> called apt-key), it relies on you trusting the fist key that you get
>>>> from them.  Since Debian doesn't actually mail out its own CDs,
>>>> everything is off its mirrors.  apt-key only 'protects' you from a
>>>> later
>>>> man-in-the-middle.
>>>>
>>>> I think that this is the central 'problem' that people are dancing
>>>> around.
>>>>
>>>> Personally, if this thread is to continue, I would like to see it
>>>> move
>>>> from a "Why doesn't OpenBSD do things this way?" to a "What are the
>>>> threat models for OpenBSD identity theft and how can we protect
>>>> ourselves?".
>>>>
>>>> Doug.
>>>>
>>>>
>>>>        
>>> --
>>> http://www.glumbert.com/media/shift
>>> http://www.youtube.com/watch?v=tGvHNNOLnCk
>>> "This officer's men seem to follow him merely out of idle curiosity."
>>> -- Sandhurst officer cadet evaluation.
>>> "Securing an environment of Windows platforms from abuse - external or
>>> internal - is akin to trying to install sprinklers in a fireworks
>>> factory where smoking on the job is permitted."  -- Gene Spafford

[Jason George]

Since this thread is both TOP and BOTTOM posted, I am going UPPER MIDDLE post.

>bofh wrote:
>> Code signing by blood.  ISAGN.
>>
>>
>> "Sorry marc - had to do it"
>>
>>  
>
>
>what if theo is a "person of interest", has his endpoint surveilled and
>his key and passphrase are compromised? if somebody stole a pint of
>blood, that could go a long way in your proposed plan...
>
>short of having a web of trust, meeting people in person to sign their
>keys and assuming private keys and passphrases have not been
>compromised, you're pretty much SOL here. best bet is to use anoncvs and
>verify your cvs server's public key in person, but even that is a PITA.
>if massive databases of key fingerprint collisions exist MITM is very
>real even with a key fingerprint, multiple fingerprints make this much
>harder.
>
>if anyone has a non-trivial quantum computer or remote viewing really
>works, the gig is pretty much up anyhow.
>
>< jy-p cinches his tinfoil hat and returns to following the yellow brick
>road... >

Like Keyser Soze, Theo has neither blood nor DNA.  Except for me at beer last
night, no one has ever seen Theo.

So everyone's point is moot.

>
>
>> On 12/6/07, Jeff I. Ragland <jeff.i.ragland@...> wrote:
>>  
>>> On 06 Dej 2007, at 5:39 LL, bofh wrote:
>>>
>>>    
>>>> You forgot one option.  Invite Theo to give a talk, and ask him to
>>>> bring the CDs.  If you can't trust Theo's CDs, all hope is lost.
>>>>      
>>> And how would you know that it is indeed Theo and not someone that
>>> looks like him? I think that blood samples and DNA tests is the only
>>> way to go here.
>>>
>>>
>>>    
>>>> Just need to make sure there're some mountains around for Theo to go
>>>> climb.  If you live on a flatland, then, sorry, you're doomed.
>>>>
>>>>
>>>> On 12/6/07, Douglas A. Tutty <dtutty@...> wrote:
>>>>      
>>>>> On Thu, Dec 06, 2007 at 11:48:55AM +0100, Hannah Schroeter wrote:
>>>>>
>>>>>        
>>>>>> One risk would be the plans of "online surveillance" of computers
>>>>>> e.g.
>>>>>> in Germany. One way to install surveillance even on OpenBSD would
>>>>>> be to
>>>>>> actively interfere with the internet connection with the surveilled
>>>>>> person, in the man-in-the-middle sense, and inject trojanned code
>>>>>> ("Bundestrojaner") into the updates of the victim.
>>>>>>          
>>>>> Using software from any source without interference from an
>>>>> all-pervasive government is a very special, but unfortunatly today, a
>>>>> very real issue for many people around the world.  To be secure, you
>>>>> have to get pieces of the puzzle over multiple paths.  It all can't
>>>>> come
>>>>> via the net since then you're open to man-in-the-middle.
>>>>>
>>>>> Key-revocation announcements could come over the net (via an announce
>>>>> list) but the new key would then have to come over a second channel.
>>>>>
>>>>> One second-channel option is the q6mth CD issue, which could
>>>>> include a
>>>>> new public key and e.g. known-hosts fingerprints.  This is
>>>>> vulnerable to
>>>>> a very determined man-in-the-middle who can replicate and then
>>>>> alter the
>>>>> CD before it arrives to you in the mail.
>>>>>
>>>>> Another option is a trusted courier flying to Alberta and get a CD
>>>>> from
>>>>> the OpenBSD store  (yeah, right).
>>>>>
>>>>> In fact, likely any other technological option (e.g. an answering
>>>>> machine in Alberta that spits out the alphanumerics of the current
>>>>> master public key) is still suceptible.
>>>>>
>>>>> If every piece of information you receive is filter through your
>>>>> government, is there any hand-shaking protocol that can allow you to
>>>>> establish a verified information connection (not necessarily
>>>>> encrypted)?
>>>>> I don't think so.
>>>>>
>>>>> Sure, Debian has signed .debs that use gpg as a back end (the
>>>>> system is
>>>>> called apt-key), it relies on you trusting the fist key that you get
>>>>> from them.  Since Debian doesn't actually mail out its own CDs,
>>>>> everything is off its mirrors.  apt-key only 'protects' you from a
>>>>> later
>>>>> man-in-the-middle.
>>>>>
>>>>> I think that this is the central 'problem' that people are dancing
>>>>> around.
>>>>>
>>>>> Personally, if this thread is to continue, I would like to see it
>>>>> move
>>>>> from a "Why doesn't OpenBSD do things this way?" to a "What are the
>>>>> threat models for OpenBSD identity theft and how can we protect
>>>>> ourselves?".
>>>>>
>>>>> Doug.
>>>>>
>>>>>
>>>>>        
>>>> --
>>>> http://www.glumbert.com/media/shift
>>>> http://www.youtube.com/watch?v=tGvHNNOLnCk
>>>> "This officer's men seem to follow him merely out of idle curiosity."
>>>> -- Sandhurst officer cadet evaluation.
>>>> "Securing an environment of Windows platforms from abuse - external or
>>>> internal - is akin to trying to install sprinklers in a fireworks
>>>> factory where smoking on the job is permitted."  -- Gene Spafford

[Ted Unangst-2]

give it a rest guys.

has anyone ever actually been the victim of some
government/corporate/"the man" attack where they slipped trojan
openbsd binaries to you?

do you have any idea how hard it really is to mount such an attack?
without being detected?  and what's the trojan going to do?  copy all
your secrets to their national citizen oppression center?  how do they
get their nefarious packets through your firewall without notice?

i've download openbsd onto various machines from at least 5 mirrors
using 9 isps in 5 countries over the course of 7 years.  and you're
telling me that every single time, somebody out there was feeding me
the bad bits?  because if they screwed up even a single time, i could
use the good machine to detect the tainted ones.  get real.

[Lars Nooden]

Ted Unangst wrote:
> give it a rest guys.

Ted says everything is ok.  We can pack up and call it a day, knowing
that everything's settled once and for all.

Seriously, if the process has been already worked out, then point to
where it is  written up.  Maybe we're not looking in the right part of
the FAQ.

-Lars

[Marco Peereboom]

HITLER AND MORE HITLER

On Thu, Dec 06, 2007 at 08:28:21PM +0200, Lars Nood??n wrote:

> Ted Unangst wrote:
> > give it a rest guys.
>
> Ted says everything is ok.  We can pack up and call it a day, knowing
> that everything's settled once and for all.
>
> Seriously, if the process has been already worked out, then point to
> where it is  written up.  Maybe we're not looking in the right part of
> the FAQ.
>
> -Lars

[beck-7]

> do you have any idea how hard it really is to mount such an attack?
> without being detected?  and what's the trojan going to do?  copy all
> your secrets to their national citizen oppression center?  how do they
> get their nefarious packets through your firewall without notice?

        Of course they won't do that. The US government has rules about
what it can collect and put in it's own databases and use. Forward thinking
people put careful rules in place preventing the government from legally
playing big brother...

        Of course it has no such rules about what data in private databases
it can in retrieve and use. The brownshirts can pretty much go in there
and get anything they want anytime. Forward thinking people kind of had
the blinders on about that one.

        Wow that Google toolbar sure is nice... ;)

        -Bob

[Christopher Linn]

there seems to be a fine, pink mist in the air.  some time ago
the matter comprising this mist was a live and healthy horse.

On Thu, Dec 06, 2007 at 12:39:39PM -0600, Marco Peereboom wrote:

> HITLER AND MORE HITLER
>
> On Thu, Dec 06, 2007 at 08:28:21PM +0200, Lars Nood??n wrote:
> > Ted Unangst wrote:
> > > give it a rest guys.
> >
> > Ted says everything is ok.  We can pack up and call it a day, knowing
> > that everything's settled once and for all.
> >
> > Seriously, if the process has been already worked out, then point to
> > where it is  written up.  Maybe we're not looking in the right part of
> > the FAQ.
> >
> > -Lars

--
Christopher Linn <celinn at mtu.edu>  | By no means shall either the CEC
System Administrator II               | or MTU be held in any way liable
  Center for Experimental Computation | for any opinions or conjecture I
    Michigan Technological University | hold to or imply to hold herein.

[Lars Nooden]

Ok.  So Christopher, Marco, and Ted have spoken up to inform the list
that they do not know an answer.

Christopher Linn wrote:
> there seems to be a fine, pink mist in the air. ...

To be sure the topic has been covered earlier, but
just where are there relevant message archives, presentations or
documents finding a practical solution to the problem of getting an
initial set of binaries?

-Lars

[STeve Andre']

On Thursday 06 December 2007 05:52:46 Hannah Schroeter wrote:

> Hi!
>
> On Wed, Dec 05, 2007 at 06:46:15PM -0500, STeve Andre' wrote:
> >[...]
> >
> >You know, you're descending into a recursive loop of "if, if, if..." and
> >it never ends.  OF COURSE if someone breaks into the site they could
> >do things--once you've lost control of your site all bets are off.  I dare
> >say that someone breaking into a site might find all the appropriate
> >tools to re-sign things, too, and do the spoof that way.
>
> If I released code with cryptographic signatures, I'd not leave a secret
> key file, nor a passphrase on the servers with the master web/ftp
> site. I'd sign on a box you can't access from the master site (nor
> the mirrors). So, no, the attacker would *not* gain access to signing
> tools (ok, yes, the tools, perhaps, like gpg or openssl, but not the
> key material).
>
> >--STeve Andre'
>
> Kind regards,
>
> Hannah.

Heh--you're intelligent.  But I know of two places where everything was
stored on the one machine, and I think one of those sites still hasn't
gotten it through their heads that this isn't a good idea.

--STeve Andre'

[Marco Peereboom]

On Thu, Dec 06, 2007 at 09:39:59PM +0200, Lars Nood??n wrote:
> Ok.  So Christopher, Marco, and Ted have spoken up to inform the list
> that they do not know an answer.

You can't possibly be this dense.  Let me try to spell it out.  YOU see
an issue WE don't.  That makes YOU responsible for fixing it.  All
reasons have been given to you why this is not even remotely a good idea
however you keep coming back for more.  So again you care we don't; how
does that make that OUR responsibility?

>
> Christopher Linn wrote:
> > there seems to be a fine, pink mist in the air. ...
>
> To be sure the topic has been covered earlier, but
> just where are there relevant message archives, presentations or
> documents finding a practical solution to the problem of getting an
> initial set of binaries?

You can't.  Either get over it or use an operating system with a trusted
vendor like Microsoft or Apple.  That pesky Open Source stuff can't be
trusted because its on the internets.

>
> -Lars

[new_guy]

Daniel Bosk wrote:

Brad, you really did start some thread. Starting with a rather
innocent question. Interesting reading though.

My best to all of you,

  Daniel

Thanks, I love OpenBSD. I see the lack of signed code and signed communication as a potential security issue. It *has* happened to other projects and I'd hate to see it happen to OpenBSD. I'd love to see PKI (specifically developer key pairs) incorporated into OpenBSD at some point... it's such a great project that produces a great product! Whatever happens, I will continue buying the CDs, T-shirts and telling my IT buddies to use it!!!

All the best,

A guy who claims to be Brad Tilley :)

[Travers Buda-2]

Paranoia is a disease...  it distorts your thinking and your logical
faculty.  I'd be more concerned about THAT if I were in your position.

It's stupid to rework the infrastructure to support signing,
especially considering the benefits (none.) Plus, you have to trust
the OpenBSD developers (GASP!) And think of all the other ways you
could be compromised, which most are much easier to implement.

Hardware keyloggers
Social engineers
Bad passwords
Physical Security?
etc.

And just what are they going to get?  Do you have some sort of
cloak-and-dagger data on your box?

--
Travers Buda