From: "A.Waschbuesch" <awaschb@gwdg.de>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: possible trojan in openssh-3.4p1
Date: Fri, 02 Aug 2002 14:18:41 +0200 [thread overview]
Message-ID: <aidt9t$7nf$1@main.gmane.org> (raw)
In-Reply-To: 200208020936.40432.you@hanez.org
Johannes Findeisen wrote:
> On Thursday 01 August 2002 15:39, Rob Kaper wrote:
>> On Thursday 01 August 2002 15:35, Terje Kvernes wrote:
>> > if the checksum differ, which it would have, emerge will abort.
>> > although, emerge logs do sound like a very good idea.
>>
>> For optimum security, emerge should check checksums from different
>> locations. One or two trusted servers (often even the same as the one
>> where the files reside, although that might not be true for gentoo)
>> can be compromised too easily.
>
> if this should be a option in portage, we always need to download two
> files from two servers to check if the md5sum are the same... :-(
> IMO it is good as it is. the gentoo-core team are providing a md5sum
> in the portage tree and that should be enough.
>
Hi Johannes,
as far as the above suggestion made by Terje is concerned You're right.
Distributed checks could easily lead to "confusion", especially working
with mirrors. But MD5 alone IS a joke when it comes to _security_
(here: proof of origin/unmodified developer version). It's quite good
to check file corruption during data transfer. But that's it in my
eyes. If one wants secure "origin" checks there's the need for gpg
signing or something alike. Just using md5 someone who got write access
to a portage-server could easily regenerate the sum and paste it into
the ebuild including a modified SRC-URL.
OK. "Even" the OpenBSD devel core team didn't manage to integrate
private keys that way (maybe in general they're chaotic). One big
problem handling this would be/is/was the key availability for people
downloading files ... at least it's like that dealing with some of the
OBSD dev-staff ...
Andrew
--
Andreas Waschbuesch, GAUniversity KG MA FNZ FK01
eMail: awaschb@gwdg.de
Pete: Waiter, this meat is bad.
Waiter: Who told you?
Pete: A little swallow.
next prev parent reply other threads:[~2002-08-02 12:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-01 8:37 [gentoo-dev] possible trojan in openssh-3.4p1 Rob Kaper
2002-08-01 8:46 ` Rob Kaper
2002-08-01 9:18 ` Vitaly Kushneriuk
2002-08-01 10:10 ` Eric Noack
2002-08-01 10:34 ` Terje Kvernes
2002-08-01 10:47 ` Rob Kaper
2002-08-01 10:56 ` Terje Kvernes
[not found] ` <200208011505.42361.bastiaf@gmx.de>
2002-08-01 13:35 ` Terje Kvernes
2002-08-01 13:39 ` Rob Kaper
2002-08-01 21:17 ` Spider
2002-08-02 7:36 ` Johannes Findeisen
2002-08-02 12:18 ` A.Waschbuesch [this message]
2002-08-02 12:02 ` [gentoo-dev] " Johannes Findeisen
2002-08-03 10:40 ` [gentoo-dev] " A.Waschbuesch
2002-08-03 16:09 ` [gentoo-dev] " Jean-Michel Smith
2002-08-03 17:19 ` [gentoo-dev] " A.Waschbuesch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='aidt9t$7nf$1@main.gmane.org' \
--to=awaschb@gwdg.de \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox