Re: Crypto signing of packages
Hi,
>>"Mark" == Mark Eichin <eichin@cygnus.com> writes:
>>"Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:
Ian> When a package is received by the archive its details are
Ian> forwarded to the validity server's front-end. This posts an
Ian> announcement on debian-devel and submits the certification
Ian> information to the validity server. This delays for 24 hours; if
Ian> the maintainer has not repudiated his signature after 24 hours
Ian> then a certificate is applied using the validity key and returned
Ian> to the archive site. This certificate binds the certification
Ian> key, the package maintainer's key and the checksum of the package
Ian> as found in the package maintainer's signature.
Mark> Hmm. This could be annoying for unstable; I've uploaded new
Mark> versions of packages in less than a day in response to feedback
Mark> from testers, and I've seen others do the same. (This is why
Mark> the recent problems with the delays in Incoming processing on
Mark> master are such a big deal...) Unless there's a seperate
Mark> less-certified "testbed" release (and if so, why have unstable?)
Mark> this seems like it would interfere with the testing cycle on
Mark> packages...
I initially was inclined to agree with Mark, but this could
less critical since uploading to master does not necessarily
mean that packages get onto the archive on ftp.debian.org, or even on
master (There are packages sitting in Incoming since last November).
Though we could consider saying that unstable is unstable and
_insecure_, and only the tested packages should be considered
secure. However, I think the percieved speed would not be seriously
affected if the verification process is periadically executed every
24 hours, and the dinstall script runs immediately after, and the
primary ftp site mirrors a couple of hours after the scheduled run of
dinstall. (Is dinstall fully automated?).
My question is whether this wait of 24 hours buys us enough to
be worth the bother? How often do we envisage a situation where a
package is uploaded signed with a key *which has been extensively
validated* in the past, but is in fact a non-maintainer upload *AND*
is caught by the maintainer n the 24 hour window? If the maintainers
key has been compromised (which one scenario), then the package could
be withdrawn from *unstable* and the maintainer key revoked as
standard practice.
IHMO, the extra wait is not justified by the gains (Oh, while
I'm do not bill myself as an security expert, I am knowledgeable in
DCE, and have contracted as a DCE/Threads/Security advisor to a well
known bank in the northeast (of the us), and baanking institutions
are as paranoid as the best of us ;-).
Ian> If a package needs to be inserted into the archive within 24
Ian> hours (security bugfixes, for example) then verification of the
Ian> package checksum and status of the maintainer's key must be
Ian> obtained through external means. Each package maintainer must
Ian> provide a telephone number and hours at which they can be
Ian> contacted. The validity server maintainer must call the package
Ian> maintainer (_not_ vice versa).
Mark> Hmm. I don't like this at all. My contribution to debian
Mark> (namely the maintenance of several large packages and a few
Mark> small ones) has not in the past required anything more than
Mark> email contact with *anyone*, and I like it that way; I can
Mark> accept phone verification of my keys up front *once* [and I'm
Mark> unimpressed by that, I much prefer in-person verification: but
Mark> frankly, there *are* no reliable ways to get in touch with me by
Mark> phone on anyone else's schedule. I have voice mail in several
Mark> places and can usually respond to it within a day or two (*much*
Mark> higher latency than email of course) but would rather not use
Mark> that channel for debian.
What does the phone call tell you? that the maintainer has
uploaded a new package? and that they believe their key to be
uncompromised? Will this offset the hassles produced by people not
being reachable? Security in the real world is a trade off. I'm not
convinced that this level of security is desired (unless we are
really working for NSA or MI-6).
Mark> This is mostly a personal thing, but it would be nice if you
Mark> could consider it in these plans; consider in particular that
Mark> the phone verification is *not* any stronger than the crypto
Mark> verification, as it is described here. (If this is limited to
Mark> security fixes, that's fine, none of the packages I maintain are
Mark> likely to need security releases; if "being available by phone"
Mark> becomes a general requirement, I'll hand over my packages to
Mark> others, because debian simply isn't worth enough to me to do
Mark> that.)
Mark> If I've misunderstood something, let me know. At very least the
Mark> text needs a better explanation of *why* the 24 hour lag is at
Mark> all useful...
I agree ...
manoj
--
... The subtlety of these methods implies an important source of
unreliability; unreliable error recovery. Thus it is important that
system testing pay meticulous attention to fault simulation to
uncover weaknesses in the recovery. Data taken on electronic
switching systems show that failure to recover from simplex faults is
usually a significant source of total outage time.... Edwin
A. Irland, "Assuring Quality and Reliability of Complex Electronic
Systems: Hardware and Software," Proceedings of the IEEE, January
1988
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: