[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: Package type: insecure, untrusted maintainers


On Mon, 17 Feb 1997, Ioannis Tambouras wrote:

> On Mon, 17 Feb 1997, Fabien Ninoles wrote:
> > On Sun, 16 Feb 1997, Ioannis Tambouras wrote:
> > 
> > >
> > >  Few days ago, I proposed that Debian should, after SOME identification
> > >  prossess, be in position to sign all of the developers keys with confidence.
> > >  Coming up with schemes of greater and greater complexity, means nothing.
> > >  The attacker will always find a way and the first victims will
> > >  raise the alarm. That is unavoidable. The proposed identification proccess
> > >  is itself rather weak, do we need radical complications? For convenience
> > >  maybe, for security no!
> > >
> > 
> > Then let us be the first "victim" : don't let a package be in stable
> > without passing through the test board. That's will be only for stable
> > and unstable will not have this delayed release features. Urgent (eg
> > security fixes) should be treat in priority (within the next few hours).
> > This will augment security and also reduced lot's of bugs.
> > 
> > just my 2 pennies :)
>   Your scheme is on the right drift!. It is classic "deadlock" detection
>  and recovery, and not trojan prevention ( which nobony here claims
>  it can be prevented). It all comes down to recovery! If there is 
>  a mechanism for speedy recovery, in no time things will be back to normal.
>  Instead, it seems, we are headed towards a wrong direction: complicated
>  delivery systems and 2-3 new bottle-necks (worst case delay is _cumulative_).
>  Could they prevent anyting? Do not know. But, for sure, recovery could take
>  weeks!. 

I always think that's a release should be done with the least patches 
possible. IMHO, patched releases are good for software development, not 
for system release. Security fixes are good (sooner is better) but bug 
fixes upgrade are bad marketing.

I think that's having a really stable, well tested distribution can 
really help to:
1) improve the Debian image and - by the same mean - those of free 
2) help to catch dependencies and packaging bugs quicker because the 
release are well known.
3) CD distributors will not have to wait until the release become stable 
because it will supposed to be (more than now already).
4) Administrators of critical system can upgrade more safely and have an 
known source (the test board) to ask which things are tested.
5) The test board will be a good place to make a how-to install/upgrade 
debian. The procedure will be well known too.

The bottle neck really depends on the efficiency of the debian test board 
but, what's up? People can still got the more recent - not tested - 
binaries from unstable.

just a little beaver ( .05 $CAN) :)

- ---------------------------------------------------------------------
 This article is a natural product.  The slight variations in 
 logic and coherence enhance its individual character and 
 beauty and in no way are to be considered flaws or defects.
- ---------------------------------------------------------------------
Fabien Ninoles aka le Veneur aka le Corbeau     
E-mail: fab@tzone.org
WebPage: http://www-edu.gel.usherb.ca/ninf01 
E-mail me with "get pgp key" in the subject to get my public key
PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99  4F 80 2D 2D 1F 85 C1 70 
- ----------------------------------------------------------------------

Version: 2.6.2


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: