Re: Bits from the RM

[Zenaan Harkness]

On Mon, 2003-12-01 at 15:45, Anthony Towns wrote:
> Having critical, grave or serious bugs open for an extended period is simply
> not acceptable.
> 
> Nor is it excusable. While it's possible that you mightn't have the skill
> required to fix some security bug, or mightn't have the time to respond
> to a bug report, you _do_ have both the time and the skill required
> to file a bug report either orphaning the package, or requesting its
> removal from the archive. 

Can "requesting removal from archive" be automated, to occur say after 3
weeks of inactivity of rc/grave/serious bug?

As a DD, I assume there is some pride and/ or utility in having your
package in the archive. This would give you a little "no nonsense"
wakeup call I would guess. And if *even the packager themselves* do not
have enough pride/ utility value in worrying at that point, then it is
likely better to get removed.

> Nor *should* it be excused. You might think the exim bug's not worth
> worrying about -- after all, exim4's what people should be using, and
> multiline Conflicts work with most tools at least, and hey shouldn't we
> think about fixing the things that don't work anyway? So who cares? The
> reporter of the bug for one. The people affected by it for another. The
> people who look at the RC bug list and decide "Oh, there are so many
> bugs already, there's no point filing another, it won't ever be fixed",
> and all the people affected by those bugs. The people who look at the RC
> bug list and decide that there's too much crap their to ever hope to make

I agree the number of RCs should come down definitely.

If automatic "request for removals" are made, they should be very
prominently advertised, so that it is easy for the users of any
particular package (who might also have pride/ utility invested in the
package) can know to do something if they want to avert the pending
situation. That could include simply emailing the DD packager (if I got
four or five emails from different users, it would tell me my work is
valued and I have a userbase worth looking after), or if they're
possibly programmatically inclined to try to patch. And (as DD again)
getting even a bad patch can be an even bigger motivation to "do it
right" for your userbase.

And if none of that happens, the package really, really should be
removed from the archive. Is there a conspiracy against anything that
might remove packages from the archive? :)

> a dent in. The people who would be willing to fix that bug, but don't want
> to have to deal with annoying the maintainer by doing an unauthorised NMU,
> or waste their time waiting for months for a an answer that'll probably be
> "no", and who spend their time doing things other than Debian work.
> 
> So, seriously, if you're inclined to think of the current state of much
> of the software we're distributing as anything but a mortifying shame,
> please correct your outlook.


> From how we're going at the moment, the best timeline we can produce
> is something like this. We'll need to reduce the RC bug count to 0 for
> at least major pieces of software like KDE, glibc and X. Each of those,
> or their dependencies, have had various RC bugs open almost continually
> since woody was released, so from that basis we can extrapolate to those
> packages continuing to have RC bugs for the next year and a half, and
> thus that we won't release for at lesat that long. Worse, those packages
> are the ones that most people like to avoid NMUing, so there's not much
> we can do on that score, either.

What happens if say there are simply not enough people interested in
GNOME for example, and the RC counts rise, and rise at an increasing
rate, and we never release again?

I guess my question is, what does it take for a package(s) to get
removed?

> is that we can re-introduce "0-day NMUs", or some similar policy to get
...
> Another possibility is to just drop packages that aren't maintained well
> enough. While this is somewhat attractive, it doesn't really serve our
> users any better than saying "Why don't we just lower our standards?"

I feel it might be the best whip there is - to start dropping packages.
Whip the users - turn them into developers I say!

The reason being, I think we've shown a few times now we can't whip
ourselves. Of course, a little package dropping might change that...

> Which is another possibility of course, and one that a number of
> maintainers seem to like when some of our policies cause problems that
> they don't want to bother fixing. It's certainly possible, and we have a
> procedure for it: argue your case on the -policy list. But concurrently
> with that, you *still* need to fix your packages -- if you're convincing,
> you can then remove the fix later, if you feel the package is better

And this is what? an observation and nothing more. It might be useful
for some, I don't know. (Me personally - "you naughty DD, not fixing
your RC because you disagree with policy - shame, shame!" - just do

Re: Bits from the RM

[Stephen M. Gava]

Anthony Towns wrote:
[...]
> Fallback plans are important though, and in this case if we're not able
> to get in a position where maintainers are able to keep control of their
> RC bug count (which is to say, keep it at zero), we'll have to consider
> more drastic measures. An obvious one is to transfer packages that aren't
> being maintained at an acceptable level to new maintainers, whether the
> existing maintainer likes it or not. Some simple measures for this are
> things like "has this package had any RC bug open for more than a month or
> two", or "has this package had an RC bug open for more than a week or so
> without any response". Even if you ignore all of the preceeding message,
> you might like to ensure that those two criteria never apply to you.

Would it be a silly idea to consider having something official in policy (or 
somewhere) outlining a minimal set of QA standards that every debian 
developer agrees to abide by (in the future as a standard part of the NM 
process), with the up-front understanding that some kind of intervention 
process (which should obviously have built-in flexibility, but should be able 
to ultimately, and as a last resort, result in loss of packages and/or 
developer status) can/will be entered into otherwise? A few fair, open, clear 
standards, a level playing field, all very sensible, no surprises for anyone.

-- 
Stephen M. Gava <[EMAIL PROTECTED]>

Re: [debian-devel] Re: Bits from the RM

[Magosányi Árpád]

A levelezőm azt hiszi, hogy Zenaan Harkness a következőeket írta:
> Can "requesting removal from archive" be automated, to occur say after 3
> weeks of inactivity of rc/grave/serious bug?
> 
> As a DD, I assume there is some pride and/ or utility in having your
> package in the archive. This would give you a little "no nonsense"
> wakeup call I would guess. And if *even the packager themselves* do not
> have enough pride/ utility value in worrying at that point, then it is
> likely better to get removed.
> 

Agreed. But beware, because we could end up with having a lot of
blue users and maintainers. To make the thing more efficient, a
good mental approach should be developed. Maybe making a request
for removal special in some ways? I think there are two things
to consider:
-make the fact as public as possible, so both the userbase and
the other developers be notified. Publicize at least two weeks
before the deadline.
-educate users and developers about how can they motivate the
maintainer to do her job well: the RFR report should include
a text explaining why the package would be removed, what
one can do to prevent this, what is the right attitude when
one communicates with the maintainer

Re: Bits from the RM

[Anthony Towns]

On Tue, Dec 02, 2003 at 05:32:59PM +1100, Zenaan Harkness wrote:

Hrm.

] $ grep Harkness /var/lib/apt/lists/*_*; echo $?
] 1

> Can "requesting removal from archive" be automated, to occur say after 3
> weeks of inactivity of rc/grave/serious bug?

It could, but it shouldn't be -- requests for removal should happen after
the analysis of whether it should be removed and what effect that'll
have has been done, not before.

> What happens if say there are simply not enough people interested in
> GNOME for example, and the RC counts rise, and rise at an increasing
> rate, and we never release again?

That's not a very interesting hypothetical -- there're plenty of people
interested in getting Gnome to work on Debian. The aim is to focus
on *fixing* the bugs, not remove the packages, and while threats can
motivate sometimes (although they often do the opposite too), it's not
really where we want to focus our attention or energies.

> I feel it might be the best whip there is - to start dropping packages.
> Whip the users - turn them into developers I say!

Nice idea, but it's not really possible; our n-m process just isn't
efficient enough for that to happen.

> And this is what? an observation and nothing more. It might be useful
> for some, I don't know. (Me personally - "you naughty DD, not fixing
> your RC because you disagree with policy - shame, shame!" - just doesn't
> do anything for me. I need a whip :)

Fundamentally, as a package maintainer you need to be responsible to
yourself.  It's not anyone else's job to come along and make sure you're
doing the right thing, it's yours. If you can't do that, or don't want
to, you should give the package to someone else, and contribute as a
co-maintainer or by filing patches.

> Allow people to demonstrate that they are lazy, and they will. 

How about we let people demonstrate that they're responsible, and capable
of being left alone?

> Can't speak to the random crackpot thing :), but I feel we need to start
> kicking some serious DD butt.

In the end, that's not something we do. Everyone here's a volunteer, and
that means we get to appreciate what they provide, and accept the limits
of their contribution. We don't get to kick their butt, we don't get to
whip them into shape, we don't get to beat them until morale improves.

Certainly, there might come a point where we need to say "look, someone
else can do a better job than you're doing, please get out of their
way and let them", but most of the time that's not actually the case,
no matter how it seems, and most of the time you're not just going to
get the package maintained somewhat better, you're also going to have
the developer you're replacing quit the project in irritation and disgust.

Almost all the time, it's far better to ensure that maintainers have
access to the help they want, and let them decide who's in a position
to replace them, and who's not.

> > A similar approach is to fix things quickly -- if you get a bug about some
> > spelling mistakes, or a simple patch to apply, do them straight away.
> How can this be "encouraged"? How do you change entrenched human
> habitual behaviour?

The first step is admitting there's a problem.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   Linux.conf.au 2004 -- Because we can.
   http://conf.linux.org.au/ -- Jan 12-17, 2004


pgpybWnI1UbRF.pgp
Description: PGP signature

Re: apt-rpm article -- the features we don't have

[Andrew Pollock]

On Mon, Dec 01, 2003 at 07:50:29PM -0800, A.J. Rossini wrote:
> 

[snip]

> 
> Joey Hess <[EMAIL PROTECTED]> writes:
> 

[snip]

> >
> > To install a package directly, with apt downloading any necessary
> > dependencies:
> >   apt-get install rpmver-2.0-13498cl.i386.rpm
> 
> couldn't this just refer to dpkg --install ?

But that won't satisfy any dependencies that the package you're installing
has.
 
> > Similarly, to check the build depends of a source package file:
> >   apt-get build-dep apt-listchanges-1.49-11104cl.src.rpm
> 
> similarly...?

See above.
 
regards

Andrew

Re: apt-rpm article -- the features we don't have

[A.J. Rossini]

Got it -- a bit more than just parsing out... but suprisingly little
(other than someone's time, which is always worth a great deal...)


Andrew Pollock <[EMAIL PROTECTED]> writes:

> On Mon, Dec 01, 2003 at 07:50:29PM -0800, A.J. Rossini wrote:
>> 
>
> [snip]
>
>> 
>> Joey Hess <[EMAIL PROTECTED]> writes:
>> 
>
> [snip]
>
>> >
>> > To install a package directly, with apt downloading any necessary
>> > dependencies:
>> >   apt-get install rpmver-2.0-13498cl.i386.rpm
>> 
>> couldn't this just refer to dpkg --install ?
>
> But that won't satisfy any dependencies that the package you're installing
> has.
>  
>> > Similarly, to check the build depends of a source package file:
>> >   apt-get build-dep apt-listchanges-1.49-11104cl.src.rpm
>> 
>> similarly...?
>
> See above.
>  
> regards
>
> Andrew
>

-- 
[EMAIL PROTECTED]http://www.analytics.washington.edu/ 
Biomedical and Health Informatics   University of Washington
Biostatistics, SCHARP/HVTN  Fred Hutchinson Cancer Research Center
UW (Tu/Th/F): 206-616-7630 FAX=206-543-3461 | Voicemail is unreliable
FHCRC  (M/W): 206-667-7025 FAX=206-667-4812 | use Email

CONFIDENTIALITY NOTICE: This e-mail message and any attachments may be
confidential and privileged. If you received this message in error,
please destroy it and notify the sender. Thank you.

libvorbis-dev missing from sarge

[Arash Bijanzadeh]

It seems to me that libvorbis package is missing from the repository of sarge. 
Trying to install kdelibs4-dev depends on libvorbis0-dev in a tree that could 
not be satisfied.

-- 
Don't go around saying the world owes you a living.  The world owes you
nothing.  It was here first.
-- Mark Twain

Assurance measures: ADO (a.k.a. input to the debsign discussion)

[Magosányi Árpád]

Hi! 


Uups, yesterday I have forgot ACM_SCP.
Today's issue is about ADO.


ACM_SCP.3 Development tools CM coverage (appears at EAL5) 
ACM_SCP.3.1D  The developer shall provide a list of 
configuration items for the TOE. 
(dpkg -l) 
ACM_SCP.3.1C  The list of configuration items shall include the 
following: implementation  representation; security flaws; 
development tools and related information; and the 
evaluation evidence required by the assurance components 
in the ST. 
(debian contains all the sources, the tools needed to compile 
itself, the documentation of both the tools and the policy. 
Maybe the DSA reports have no package yet, but it should be 
easy to create one.

ADO_DEL.3 Prevention of modification (appears at EAL7)
(the current deb signing discussion aims at this requirements)
ADO_DEL.3.1D  The developer shall document procedures for delivery of
the TOE or parts of it to  the user.
(this is done in multiple documents)
ADO_DEL.3.2D  The developer shall use the delivery procedures.
(this is the case)
ADO_DEL.3.1C  The delivery documentation shall describe all procedures
that are necessary to  maintain security when distributing
versions of the TOE to a user's site.
(not everything is here, but arguably nearly all steps are
done)
ADO_DEL.3.2C  The delivery documentation shall describe how the various
procedures and technical measures provide for the prevention of
modifications, or any discrepancy between the developer's
master copy and the version received at the user site.
(if there is no such description, it can easily compiled from
the debsign thread)
ADO_DEL.3.3C  The delivery documentation shall describe how the various
procedures allow detection of attempts to masquerade as the
developer, even in cases in which the  developer has
sent nothing to the user's site.
(this will eventually be an option to apt, I guess)

ADO_IGS.2 Generation log (not appears even at EAL7)
ADO_IGS.2.1D  The developer shall document procedures necessary for the
secure installation, generation, and start-up of the TOE.
(several guides)
ADO_IGS.2.1C  The installation, generation and start-up documentation
shall describe the steps necessary for secure installation,
generation, and start-up of the TOE.
(I guess they describe those steps. If not, a quick rereading
would insert the necessary notes.)
ADO_IGS.2.2C  The installation, generation and start-up documentation
shall describe procedures capable of creating a log containing
the generation options used to generate the TOE in such a way
that it is possible to determine exactly how and when the TOE
was generated.
(The build log created by debuild is even more than that)

>From the next issue: Class ADV (development), or what we are really bad
at, part 1?

-- 
GNU GPL: csak tiszta forrásból

Re: [custom] Re: Custom Debian Distributions

[Andreas Tille]

On Tue, 2 Dec 2003, Zenaan Harkness wrote:

> Is there a single place where all official Custom Debian Distributions
> (CDDs - even a reasonable TLA), aka internal projects, are listed?
Unfortunately not yet under www.debian.org, but if the redirection
loop to people.debian.org is solved again you might consider reading

 http://people.debian.org/~tille/debian-med/talks/200311_lux_cust

This is my current talk about "Custom Debian Distributions" I held at
LinuxDays Luxembourg containing all known (to me) projects with URLs and
relevant people.  I'll prepare a written paper (hopefully) soon.  I wished
there were more relevant docs about this topic and a common page at
www.debian.org but I did not found enough time to care about this in the
past.

Moreover there is

  http://www.debian.org/intro/organization

where you can find some (not all - for instance Debian-Np is missing)
listed in the end under the old name "Internal Projects".

> > These Custom Distributions use the technique of metapackages and have
> > common goals and try to develop common technologies.
>
> Should have a [EMAIL PROTECTED] list then...
See #160229.

> > reference.  In Oslo was a decision to name it "Custom Debian Distribution"
> > and if we try to speak with each other we have to agree about some
> > terms.  This thread shows that there is not yet an agreement and this
> > sucks because we have to explain over and over again what we are talking
> > about.
>
> Actually, it feels to me like we've come to a rough concensus on Custom
> Debian Distribution. There is agreement a single term is a good thing,
> perhaps with sub-definitions. No one (unless I missed it) has proposed a
> better name that hasn't had problems pointed out. I think.
I have no problems with any name because I'm generally holding my breath
in naming discussions.  On the other hand people who invented a name should
care for populating the meaning to avoid confusion.  This was not yet done
and *this* is the problem.

> > For instance we have defined a term "Package Pools" and everybody now
> > knows what we are talking about ...
>
> Exactly.
>
> It comes down to people using it. How would one go about creating a
> common location for pointers to all of these CDDs?
Just go for it.  You can get CVS access to wml pages even if you are
not a DD.

> Then, it's up to the projects to start using the term. A list would I
> think be very good for making cdd discussions stand out at this point -
> there seems to be enough traffic. But perhaps I'm wrong, I don't know.
You are completely right.  I'm feeling quite alone in propagating the idea
(if you keep in mind that also the patch fo 
www.debian.org/intro/organization.wml
was done by me).  But I would like to spend my power more to Debian-Med
instead of doing the work for all those CDDs. :-(

Kind regards

   Andreas.

Re: KDE broken in sarge repository- solution is at DebianKDE wiki

[Arash Bijanzadeh]

On Monday 01 December 2003 16:07, Hereon wrote:
> On Mon, 1 Dec 2003 15:51:37 +0330, "Arash Bijanzadeh"
>
> <[EMAIL PROTECTED]> said:
> > On Sunday 30 November 2003 18:10, Steve Langasek wrote:
> > > Er, on what grounds are you claiming that this is broken?  The
> > > dependencies declared by these packages have specifically NOT been
> > > broken in sarge: kdelibs 3.1.4 claims to provide a set of libraries
> > > that are compatible with kdelibs 3.1.3, and it should be entirely
> > > possible to run 3.1.3 versions of programs with the 3.1.4 libraries. 
> > > If you have reason to believe otherwise, you'll need to be more
> > > specific (and file a bug against the package in question).
> >
> > OK, I was wrong about it. But i can't install kde and that is because:
> > kdebase depends on ksysguard thats depends on ksysguardd which in turn is
> > depend on libsensors-1debian1
> > But I could not find the last package in the debian repository.
> > Can you help me please?
>
> The following is a very useful page for KDE.
> You should find the answer to your problem there.
> DebianKDE
> http://wiki.debian.net/index.cgi?DebianKDE
>

I got to download libsensors-1debian1 from another site and kdebase installed 
after that. 
IMHO it is not correct, after all talking about the sarge repository still I 
can say that it is broken.

-- 
Don't go around saying the world owes you a living.  The world owes you
nothing.  It was here first.
-- Mark Twain

Re: Bits from the RM

[Brian May]

On Tue, Dec 02, 2003 at 05:32:59PM +1100, Zenaan Harkness wrote:
> Can "requesting removal from archive" be automated, to occur say after 3
> weeks of inactivity of rc/grave/serious bug?
> 
> As a DD, I assume there is some pride and/ or utility in having your
> package in the archive. This would give you a little "no nonsense"
> wakeup call I would guess. And if *even the packager themselves* do not
> have enough pride/ utility value in worrying at that point, then it is
> likely better to get removed.

A release critical bug in one package could be caused by a non-release
critical bug in another package.
-- 
Brian May <[EMAIL PROTECTED]>

Re: Revival of the signed debs discussion

[Thomas Viehmann]

Martin Michlmayr ([EMAIL PROTECTED]) wrote:
>
>* Thomas Viehmann <[EMAIL PROTECTED]> [2003-12-01 15:30]:
>> BTW: This is offtopic, but it seems that potato is neither in debian/
>> nor in debian-archive/?
>Potato is on archive.debian.org (in /debian-archive/dists).

Ah. Thanks.
ftp.debian.org/debian-archive and ftp.de.debian.org/debian-archive do a good 
job at
imitating an archive without potato...

Cheers

T.

Re: [custom] Debian Enterprise - a Custom Debian Distribution

[Andreas Tille]

On Tue, 2 Dec 2003, Zenaan Harkness wrote:

> > ?  It might help you registering a site under www.debian.org (once its
> > services are up again.
>
> Cool. I'll check it out in a day or five :)
If you are interested I could send you my CDD - talk stuff in private mail
until people.d.o is up again.

> debian-enterprise, yet I think that technical goals will be more closely
> coincident than might at first be obvious :)
Definitely.  I think we could do several technical stuff which all CDDs could
profit very much.  But it has to be done in common...

Kind regards

 Andreas.

Re: Debian Enterprise?

[Zenaan Harkness]

On Mon, 2003-12-01 at 22:36, Alexander Kitzberger wrote:
> we and a couple of other linux companies are also thinking this way,
> and we would like also to support a enterprise debian.

Great stuff ... we are forming it now. As you probably well know by now,
there's a web page started at:
http://debian-enterprise.org/

> We have the problem that debian has to compete to suse and red hat
> enperprise servers which are certified for oracle, etc.

Yes, raising our profile as an Enterprise Operating System I think is
going to be very useful and productive medium to long term (takes a
while to actually do). And so we are starting.

> We like the idea in having also a enterprise debian to have a 
> alternative, because we like using debian more that other distributions.

:)

So do many of us.

> Please inform me if you have any other new regarding this project.

Keep an eye on this list - debian-devel, as a dedicated mailing list is
on its way (hopefully soon). I also subscribe to debian-devel-announce,
which might be useful.

> I talked to joey a few weeks ago about an ideas that goes into the same 
> direction:
> 
> This is a extract of my conversation with joey:
> --
> Hello Joey,
>  > we and some other linux companies are thinking about some
>  > things for a while. And now the aquisition of suse make this more actual.
>  >
>  > We and the other companies would like to start a new sub-project
>  > under the debian project that may be called "business debian"
>  > or "enterprise debian"
>  >
>  > The aim of this project is to make a homepage (subdomain or subsection
>  > od the debian homepage) to present case studies and reference projects
>  > that service companies like us realized.
> ---

Bruce Perens is raising funds for a project that will hopefully directly
relate to debian-enterprise.

Great to have you on board,
Zenaan

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: Bits from the RM

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Anthony Towns   wrote:
>Without having evaluated null hypotheses or done exhaustive analyses,
>the correlation nevertheless seems fairly convincing. To put it bluntly,
>our regular package maintainers are doing such a bad job that without
>significant assistance from NMUs, about 6% of the archive fails to meet
>even our _absolute minimum_ expectations.
>
>That's bad.
>
>It would be bad even if the 6% was random junk that no one uses or cares
>about, or was a bunch of packages that were so complicated no one knows
>how to fix them, which is probably what you're thinking. Unfortunately,
>it's even worse than that. Consider the following examples:

I really think you should look at the activity on a bug as well. If
there's a grave bug filed against a package, see if there's any
reply from the maintainer in that bug report. Sure, a grave bug might
be open for a month, and if the maintainer ignores it that is
very bad, but if there's an active discussion going on on
the relevant [EMAIL PROTECTED] address you can't say the
maintainer is ignoring it.

Just my EUR .02

Mike.

Re: Bits from the RM

[Antti-Juhani Kaijanaho]

On 20031201T144509+1000, Anthony Towns wrote:
>   * #208646 - grep-dctrl - Antti-Juhani Kaijanaho
> unspecified problems with version in unstable, should take
> "a couple of days" to fix, no activity since September

The "unspecified problems" are mainly recorded in the other open bugs
against that package.  The main issue is that the rewrite is not yet as
good quality-wise as the old version (which is in testing), and thus I'd
prefer to release the old version instead of the new one unless I am
able to fix the  new one in time.  The current unstable version probably
does not belong in unstable according to the "new" definition of what
unstable is, but the rewrite went in a week or two before the new
definition was published, and I haven't had the energy to arrange having
the old version again in unstable and then uploading the new one to
experimental (when I have that kind of energy, I'd prefer to put it to
fixing the new package).

That said, it has been too long since I last looked at grep-dctrl.  I'll
try to fix that "in a couple of days" :)  I can only say that my
teaching duties have exhausted me during the autumn.

-- 
Antti-Juhani Kaijanaho, Debian developer   http://www.iki.fi/gaia/


signature.asc
Description: Digital signature

Re: Demudi.org

[Andrea Glorioso]

> "ag" == Andrea Glorioso <[EMAIL PROTECTED]> writes:

> "t" == Tom  <[EMAIL PROTECTED]> writes:
t> One of the "flavors" linked to on
t> http://www.debian.org/devel/debian-nonprofit/ is www.demudi.org
t> --

t> which is running IIS on Windows 2000!

ag> demudi.org is a round-robin record.  I'm currently checking
ag> this issue - I'll remove that record from the DNS zone once I
ag> understand who it actually points to.

A little update.

I finally managed to convince mydomain.com that *I* was the master and
not the reverse.

www.demudi.org now (wait for DNS-propagation time, of course) points
to 130.237.67.101, which is a brand, shining Debian GNU/Linux server.
The domain actually is rewritten to www.agnula.org.

I'm still studying how to move devel.demudi.org so not to disrupt its
services.

The MX and other third-level domains have been left intact.

Hope this helps,

andrea
--
Andrea Glorioso[EMAIL PROTECTED]
AGNULA/DeMuDi Techie   http://www.agnula.org/
"There's no free expression without control on the tools you use"

Re: [custom] Debian Enterprise - a Custom Debian Distribution

[Enrico Zini]

On Tue, Dec 02, 2003 at 01:05:29AM +0100, Enrico Zini wrote:

> > >  - GNU ERP software project ?name?
> > GNU Enterprise (gnue)  http://www.gnue.org/
> I've just learnt of Cubit from South Africa: http://www.cubit.co.za/

...and of the Impi distribution from South Africa, Debian-based:

   Welcome to Impi Linux, South Africa's first business desktop Linux
   distribution.

   Impi Linux was created from the best software available in the open
   source world, to give South African users a stable, virus free and
   very cost effective business operating system.

   Impi Linux is not just an operating system, but comes bundled with
   every application that you need to run your business, Accounting,
   word processing, spreadsheets, web browsing, email and much, much
   more.

   (from http://www.impi.org.za, more info in the About link)


And also (from http://www.impi.org.za/support.html):

   Impi Linux is one of the first Linux distributions to be released
   with a 24/7 telephonic support centre.  You could also join your
   Local Linux Users' Group such as GLUG or you can use an Internet
   search engine such as Google for Linux.


Lastly (from http://www.impi.org.za/contact.html)

   General enquiries, press, marketing and sales:
   Ross Addis <[EMAIL PROTECTED]>

   (hint, hint, hint :)


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Revival of the signed debs discussion

[Andreas Barth]

* Goswin von Brederlow ([EMAIL PROTECTED]) [031202 04:55]:
> Andreas Barth <[EMAIL PROTECTED]> writes:
> > Technical details should IMHO be discussed later, but a sample
> > passport could look like:
> > 
> > accepted by katie on Mon,  1 Dec 2003 20:34:58 + because of good 
> > signature of DD, KeyID 0x01234567
> > build by DD on Sun, 30 Nov 2003 14:34:33 +0100
> > mgetty-voice_1.1.30-6_i386.deb
> > 450b2b4ffa0be49b43f7358099117f7d control.tar.gz
> > fb00a05d140ec3e830d6227f3fdd743d data.tar.gz

> All debs would contain the same string "accepted by katie on * because
> of good signature of DD, KeyID *". Thats a lot of bytes wasted.

There is a mere misunderstanding. If you singned the deb, katie would
write "accepted by katie on * because of good signature of Goswin von
Brederlow <[EMAIL PROTECTED]>, KeyID 0x...". And of
course, this string should be made shorter, but that's something we
can at the moment leave for later discussion IMHO. It could e.g. be:
"katie: 2003-...: sig ok, Goswin von Brederlow <[EMAIL PROTECTED]>, 0x"

> The date is already stored in the ar archive so thats wasted too.

Almost everything is "already stored in the ar archive". But not in a
secure way. The question is just: Which information is needed to be
secured. And I for myself want the day something was transfered to the
pool to be signed.


> Each signing instance should have an unique key. They key ID then
> identifies who signed it and the reason (being allways the same) could
> be documented in some Readme.

The reason is not always necessarily the same, e.g. if someone
sponsors someone else. However, this could be solved with your proposal.

> I agree with you that every instance along the way to the archive
> should sign the package:

fine.


> debsigs allows for 10 chars for the name of the signature.
> 8 chars would be key ID.
> 1-2 chars could be used to denote the reason of the signature:
> 
> DM - DD maintainer
> NM - non DD maintainer
> DN - non maintainer upload by a DD
> NN - non maintainer non dd upload
> SP - sponsor
> BD - buildd
> BA - buildd admin
> DI - deinstall

Good idea.



Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Backport of the integer overflow in the brk system call

[Andreas Metzler]

Frederik Dannemare <[EMAIL PROTECTED]> wrote:
> just curious: any particular reason why we didn't see a backport any sooner 
> of 
> the integer overflow in the brk system call (see recent announcement by 
> Wichert Akkerman: 
> http://lists.debian.org/debian-security-announce/debian-security-announce-2003/msg00212.html)
>  
> like we did with the ptrace issue some time back?

> Wasn't it (the brk vuln) considered to be threatening enough to justify a 
> quick fix, or was it because the fix by Andrew Morton didn't say (kerne 
> changelog) enough about the potential seriousness of the vuln, or?

Apparently nobody knew it was comparable to ptrace, it looked like a
simple bugfix and not like a local root exploit.

| Robert van der Meulen managed to decrypt the binary which revealed
| a kernel exploit.
   cu andreas

Re: [debian-devel] Re: Bits from the RM

[Zenaan Harkness]

On Tue, 2003-12-02 at 18:12, Magosányi Árpád wrote:
> A levelezőm azt hiszi, hogy Zenaan Harkness a következőeket írta:
> > Can "requesting removal from archive" be automated, to occur say after 3
> > weeks of inactivity of rc/grave/serious bug?
> > 
> > As a DD, I assume there is some pride and/ or utility in having your
> > package in the archive. This would give you a little "no nonsense"
> > wakeup call I would guess. And if *even the packager themselves* do not
> > have enough pride/ utility value in worrying at that point, then it is
> > likely better to get removed.
> > 
> 
> Agreed. But beware, because we could end up with having a lot of
> blue users and maintainers. To make the thing more efficient, a
> good mental approach should be developed. Maybe making a request
> for removal special in some ways? I think there are two things
> to consider:
>   -make the fact as public as possible, so both the userbase and
>   the other developers be notified. Publicize at least two weeks
>   before the deadline.
>   -educate users and developers about how can they motivate the
>   maintainer to do her job well: the RFR report should include
>   a text explaining why the package would be removed, what
>   one can do to prevent this, what is the right attitude when
>   one communicates with the maintainer

Excellent points, thanks.
Zenaan

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: Revival of the signed debs discussion

[Andreas Barth]

* Joey Hess ([EMAIL PROTECTED]) [031202 02:55]:
> Goswin von Brederlow wrote:
> > What can we do with deb signatures?
> > 
> > For our current problem, the integrity of the debian archive being
> > questioned, the procedure would be easy and available to every user:
> > 
> > 1. get any clean Debian keyring (or just the key signing the keyring)
> > 2. verify the latest Debian keyring
> > 3. verify that each deb was signed by a DD and the signature fits

> The canoical attack against signed debs in this situation is to find a
> signed deb on snapshot.debian.net that contains a known security hole.

To avoid this attack, it is necessary that the filename of the deb or
the version of the package is also signed.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Backport of the integer overflow in the brk system call

[Tom]

On Tue, Dec 02, 2003 at 10:08:03AM +0100, Andreas Metzler wrote:
> 
> Apparently nobody knew it was comparable to ptrace, it looked like a
> simple bugfix and not like a local root exploit.
> 

Well, I just downloaded 2.4.23 from kernel.org and installed it.

[obGrumble] I never got hit by any of the Microsoft exploits either but 
I hated the upgrade treadmill [end].  Of course this is the 1st one in 
Linux for me and I'm willing to give y'all the benefit of the doubt 10 
or 11 times :-)

Was this problem a deviation from well-established security practices or 
is a new thing?  Could somebody explain it in a nutshell?

Re: [custom] Custom Debian Distributions

[Benj. Mako Hill]

On Tue, Dec 02, 2003 at 05:38:15AM +1100, Zenaan Harkness wrote:
> On Tue, 2003-12-02 at 02:46, Anthony Towns wrote:
> > So, using my definitions, the following conclusions are (IMO) true:
> > 
> > * all flavours are policy compliant
> > 
> > * some derived distros might be policy compliant
> 
> Do you mean to include, eg. derived distros including non-free software
> here, or should we have a separate term for this?

If the derived distro is outside of Debian from a "project" sort of
view, they don't have to upload the social contract, respect the DFSG
and developer GRs. All internal projects that bear the Debian name
must, at the very least, do this to the extent that Debian proper
does or it's kind of strange calling them Debian. No?

> > * distributing customised Debian distros is not only the way of the
> >   future, it's the way of the present!

Nice. :)

Regards,
Mako


-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.yukidoke.org/



pgpiWNVF5WBCn.pgp
Description: PGP signature

Re: Revival of the signed debs discussion

[Tom]

On Tue, Dec 02, 2003 at 11:07:53AM +0100, Andreas Barth wrote:
> * Joey Hess ([EMAIL PROTECTED]) [031202 02:55]:
> > Goswin von Brederlow wrote:
> > > What can we do with deb signatures?
> > > 
> > > For our current problem, the integrity of the debian archive being
> > > questioned, the procedure would be easy and available to every user:
> > > 
> > > 1. get any clean Debian keyring (or just the key signing the keyring)
> > > 2. verify the latest Debian keyring
> > > 3. verify that each deb was signed by a DD and the signature fits

What precautions are taken that the DD actually signed it with the DD's 
private key?  After all this compromise was due to a DD's machine being 
compromised.  I don't think you can audit every DD's workstation to make 
sure the keys are well managed.

Set aside the possibility that the DD herself is actually the attacker.  
You have to have an answer for these remote possibilities.  (Things tend 
to get maximally bad).

> 
> > The canoical attack against signed debs in this situation is to find a
> > signed deb on snapshot.debian.net that contains a known security hole.
> 
> To avoid this attack, it is necessary that the filename of the deb or
> the version of the package is also signed.

Re: [custom] Re: Custom Debian Distributions

[Zenaan Harkness]

On Tue, 2003-12-02 at 19:14, Andreas Tille wrote:
> On Tue, 2 Dec 2003, Zenaan Harkness wrote:
> > Then, it's up to the projects to start using the term. A list would I
> > think be very good for making cdd discussions stand out at this point -
> > there seems to be enough traffic. But perhaps I'm wrong, I don't know.
> You are completely right.  I'm feeling quite alone in propagating the idea
> (if you keep in mind that also the patch fo 
> www.debian.org/intro/organization.wml
> was done by me).  But I would like to spend my power more to Debian-Med
> instead of doing the work for all those CDDs. :-(

I'll put together the notes for your talk and a bit about terminology on
a Wiki as soon as I figure it out - may be tomorrow. Do you have a
mirror of your talk that's not on people.d.o?

Thanks for all your positive pointers. Much appreciated.
Zenaan

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: [debian enterprise] sub-project planning

[Benj. Mako Hill]

On Tue, Dec 02, 2003 at 06:24:58AM +1100, Zenaan Harkness wrote:
> I guess if you're a DD (I'm in the NM-process myself), you can creake
> "official" Debian wiki, etc?

AFAIK, the "official" Debian wiki is http://wiki.debian.net and like
most wikis, *anyone* can create a page. Please go ahead and do so.

Create a new page linked from
http://wiki.debian.net/index.cgi?CustomDebian and then work from
there.

When you get to a stage where you need a www.d.o page, you won't need
to be a developer to get one of those either I don't believe.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.yukidoke.org/



pgpOcDU2OZqm3.pgp
Description: PGP signature

Re: Bits from the RM

[Nikita V. Youshchenko]

> On Tue, Dec 02, 2003 at 05:32:59PM +1100, Zenaan Harkness wrote:
>> Can "requesting removal from archive" be automated, to occur say after 3
>> weeks of inactivity of rc/grave/serious bug?
>> 
>> As a DD, I assume there is some pride and/ or utility in having your
>> package in the archive. This would give you a little "no nonsense"
>> wakeup call I would guess. And if *even the packager themselves* do not
>> have enough pride/ utility value in worrying at that point, then it is
>> likely better to get removed.
> 
> A release critical bug in one package could be caused by a non-release
> critical bug in another package.

Doesn't this mean that "non-release critical bug in another package" should 
become release critical?

Re: Bits from the RM

[Zenaan Harkness]

On Tue, 2003-12-02 at 18:09, Anthony Towns wrote:
> On Tue, Dec 02, 2003 at 05:32:59PM +1100, Zenaan Harkness wrote:
> ] $ grep Harkness /var/lib/apt/lists/*_*; echo $?
> ] 1

It's not much (directly) Debian related (yet), but:
I'd be in NM but for the keyservers and NM registration page being down.
I have packaged fastdep, and it is being reviewed, and has been through
a few rounds of suggestions and repackaging:

http://homepages.ihug.com.au/~zenaan/zenaan/files/

> > Can "requesting removal from archive" be automated, to occur say after 3
> > weeks of inactivity of rc/grave/serious bug?
> 
> It could, but it shouldn't be -- requests for removal should happen after
> the analysis of whether it should be removed and what effect that'll
> have has been done, not before.

OK

> > I feel it might be the best whip there is - to start dropping packages.
> > Whip the users - turn them into developers I say!
> 
> Nice idea, but it's not really possible; our n-m process just isn't
> efficient enough for that to happen.

OK. I was thinking more of - if they are told their favourite package is
about to get removed (it's a stick for the users of the package, not
only the developer), then the user might be motivated to at least send
an email to someone, and slowly get educated - if nothing else, about
sending emails. That is a useful part of the process. My intention is
"how can this be emphasized".

> > And this is what? an observation and nothing more. It might be useful
> > for some, I don't know. (Me personally - "you naughty DD, not fixing
> > your RC because you disagree with policy - shame, shame!" - just doesn't
> > do anything for me. I need a whip :)
> 
> Fundamentally, as a package maintainer you need to be responsible to
> yourself.  It's not anyone else's job to come along and make sure you're
> doing the right thing, it's yours. If you can't do that, or don't want
> to, you should give the package to someone else, and contribute as a
> co-maintainer or by filing patches.

Except it appears the current process of expecting the developer to
realise at what point this has occured by themself, is not efficient
enough given current size of debian + desired release schedules +
current process for [notifying|whipping] developers.

> > Allow people to demonstrate that they are lazy, and they will. 
> 
> How about we let people demonstrate that they're responsible, and capable
> of being left alone?

Definitely. I'm sorry if my comments were not smileyed enough. I
understand that I was presenting an extreme viewpoint. It was more for
the point of getting the viewpoint down (and I was hoping in a
lighthearted way).

> > Can't speak to the random crackpot thing :), but I feel we need to start
> > kicking some serious DD butt.
> 
> In the end, that's not something we do. Everyone here's a volunteer, and
> that means we get to appreciate what they provide, and accept the limits
> of their contribution. We don't get to kick their butt, we don't get to
> whip them into shape, we don't get to beat them until morale improves.

:)

Point taken (I found your paragraph above pretty humorous, in a good
way).

> Certainly, there might come a point where we need to say "look, someone
> else can do a better job than you're doing, please get out of their
> way and let them", but most of the time that's not actually the case,

I would be the first to give a developer who desires to continue working
on their package and being a maintainer, etc, every possible opportunity
and support to do so (eg. deferring RC-driven package removals, etc).

Thanks for clarifying this point though - I agree it is central to The
Debian Way. We are all volunteers and that is understood. I'm just
guessing there might be some additional email notifications or whatever,
that can raise the awareness a little, in alignment with what you first
proposed.

> no matter how it seems, and most of the time you're not just going to
> get the package maintained somewhat better, you're also going to have
> the developer you're replacing quit the project in irritation and disgust.
> 
> Almost all the time, it's far better to ensure that maintainers have
> access to the help they want, and let them decide who's in a position
> to replace them, and who's not.

That shouldn't sound in conflict to what I wrote. I'm in agreement here.

> > > A similar approach is to fix things quickly -- if you get a bug about some
> > > spelling mistakes, or a simple patch to apply, do them straight away.
> > How can this be "encouraged"? How do you change entrenched human
> > habitual behaviour?
> 
> The first step is admitting there's a problem.

Good point.

Thanks for your very measured response. I do apologise if my email came
across too harshly.

cheers
zenaan

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibl

Re: Bits from the RM

[Zenaan Harkness]

On Tue, 2003-12-02 at 18:56, Brian May wrote:
> On Tue, Dec 02, 2003 at 05:32:59PM +1100, Zenaan Harkness wrote:
> > Can "requesting removal from archive" be automated, to occur say after 3
> > weeks of inactivity of rc/grave/serious bug?
> > 
> > As a DD, I assume there is some pride and/ or utility in having your
> > package in the archive. This would give you a little "no nonsense"
> > wakeup call I would guess. And if *even the packager themselves* do not
> > have enough pride/ utility value in worrying at that point, then it is
> > likely better to get removed.
> 
> A release critical bug in one package could be caused by a non-release
> critical bug in another package.

That the former package's maintainer must fix I guess?

Is this a particularly common occurrence?

ta
zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)

[Eduard Bloch]

Moin Goswin!
Goswin von Brederlow schrieb am Tuesday, den 02. December 2003:

> > I would like to see the following things happen:
> > 
> >  - current md5sums file in control.tar.gz should contain
> >checksums of really all files
> >  - a signature of the md5sums file should be stored either in
> >control.tar.gz or in the ar file itself
> >  - new dpkg version should pickup the signature files and store them
> >either in /var/lib/dpkg/info or in some alternative directory
> >  - modify debsums to check the signature as well as maintainer scripts'
> >checksums
> > 
> > Any additions, comments, etc.?
> 
> If you think files of a deb are compromised on your system what makes
> you thing the md5sum files are not? Storing the md5sum files on-site
> will only help against accidental (or stupid) changes.

Because you store the extra signatures of md5sum files in a separate
location, as said above. But as Goswin and other stated before, the gain
(securitywise) is low compared to the costs of extra signing and
handling with the signature file. So I see another good method to verify
the already installed files: create an extended version of the current
Contents-ARCH files including the md5 checksums of each file from each
package and sign this Md5Contents file with some official key.

> Also since the complete deb is just as save as the md5sumsfile
> contained in the deb it is pointless to have such. People who realy
> want to store the md5sums file should create it during install time
> (let dpkg do that). The md5sums file still requires one to download

As said before, some people may not run tripwire&Co. during the initial
installation and enable such modification detection systems later. There
should be a way to feed the database with known good md5sums afterwards,
see above.

> the complete deb from a trusted source to verify the installed
> system. But then why not just do a 1:1 compare?
> 
> After all this ranting about how useless a md5sums file is here's an
> idea:
> 
> 1. No md5sums files are contained in the deb itself.

You mean in the deb as created by dpkg-deb during the build? Okay, the
functionality may be moved to the second step (below), but then
dh_md5sums should be converted to a dummy script and debhelper conflict
with the older versions of dpkg-dev.

> 2. dpkg-genchanges unpacks the deb (control and data) and creates a
>sorted md5sums file (sorted by md5sum, by filename or whatever. But
>reproducible). A signature of the md5sums file (md5sum of it?) is
>then added to the change file.

As we agreed on IRC, the contents of control.tar.gz should be included
too. Idealy extracted temporarily into
$tmpdir/var/lib/dpkg/info/pkgname.FILE so debsums gets full paths and
has easy job later.

MfG,
Eduard.
-- 
Um die Welt zu ändern, sie neu zu gestalten, müssen zuvor die Menschen
sich selbst umstellen.
-- Fjodor Michailowitsch Dostojewski

Re: [custom] Re: Custom Debian Distributions

[Zenaan Harkness]

On Tue, 2003-12-02 at 19:14, Andreas Tille wrote:
> On Tue, 2 Dec 2003, Zenaan Harkness wrote:
> > Is there a single place where all official Custom Debian Distributions
> > (CDDs - even a reasonable TLA), aka internal projects, are listed?
> Unfortunately not yet under www.debian.org, but if the redirection

I just realised I'm going loopy - the wiki is the place, and it's
already half set up:

http://wiki.debian.net/?CustomDebian

Sorry, I need some sleep now I guess... I'll see about collating other
stuff there...

rgds
zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: [custom] Debian Enterprise - a Custom Debian Distribution

[Zenaan Harkness]

On Tue, 2003-12-02 at 20:46, Enrico Zini wrote:
> On Tue, Dec 02, 2003 at 01:05:29AM +0100, Enrico Zini wrote:
> > > >  - GNU ERP software project ?name?
> > > GNU Enterprise (gnue)  http://www.gnue.org/
> > I've just learnt of Cubit from South Africa: http://www.cubit.co.za/
...
> ...and of the Impi distribution from South Africa, Debian-based:
>(from http://www.impi.org.za, more info in the About link)
...
> Lastly (from http://www.impi.org.za/contact.html)
> 
>General enquiries, press, marketing and sales:
>Ross Addis <[EMAIL PROTECTED]>

Thanks for the references. Will add them to CDD WIKI and
debian-enterprise web pages...

cheers
zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: [debian enterprise] sub-project planning

[Zenaan Harkness]

On Tue, 2003-12-02 at 21:41, Benj. Mako Hill wrote:
> On Tue, Dec 02, 2003 at 06:24:58AM +1100, Zenaan Harkness wrote:
> > I guess if you're a DD (I'm in the NM-process myself), you can creake
> > "official" Debian wiki, etc?
> 
> AFAIK, the "official" Debian wiki is http://wiki.debian.net and like
> most wikis, *anyone* can create a page. Please go ahead and do so.

Cool stuff. Thanks for the pointers,
Zenaan

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Assurance measures: ADV (what we are really bad at)

[Magosányi Árpád]

Hi!

The saga continues. Now we look at the development assurance
measures. Unfortunately this part is where open source is
not good at (not saying that closed source is better).
This is because writing documentation is quite
boring, and ADV is about writing design documentation.

I personally think that the mental activities behind this
assurance class are done in most part, and most of the
information is available scattered throught mailing lists
and documentations. Also, the code speaks for itself:)
Unfortunately this is not an excuse.

I would be happy to find that my assumptions are false, so
feel free to correct me.

I will only list requirements corresponding to EAL3 where
they are not easily met.

ADV_FSP.1 Informal functional specification (EAL1-3)
ADV_FSP.1.1D   The developer shall provide a functional specification.
(Well, this is lacking for the distribution as a whole,
and for most of the packages.)
ADV_FSP.1.1C   The functional specification shall describe the TSF and
its external interfaces using an informal style.
(The trusted security functions aren't identified.
However if they would be identified, the corresponding manpages
would more than suffice.)
ADV_FSP.1.2C   The functional specification shall be internally
consistent.
(I think the manpages meet this)
ADV_FSP.1.3C   The functional specification shall describe the purpose
and method of use of all external TSF interfaces, providing
details of effects, exceptions and error messages, as
appropriate.
(Also, man pages meet this)
ADV_FSP.1.4C   The functional specification shall completely represent
the TSF.
(If we would know what the TSF is...)

ADV_FSP.2.5 is EAL4, and more with the following requirement:
ADV_FSP.2.5C The functional specification shall include rationale
that the TSF is completely represented.
(I guess it would be easy to do if we could define the TSF).


ADV_HLD.2 Security enforcing high-level design (EAl3, EAL4)

ADV_HLD.2.1D The developer shall provide the high-level design of the
TSF.
(Some packages have developers' guide. Some don't. Those
which have may or may not give an appropriate high level
design.)
ADV_HLD.2.1C The presentation of the high-level design shall be
informal.
(well, if they have, it is informal)
ADV_HLD.2.2C The high-level design shall be internally consistent.
(sometimes...)
ADV_HLD.2.3C The high-level design shall describe the structure of the
TSF in terms of subsystems.
(some do, some don't)
ADV_HLD.2.4C The high-level design shall describe the security
functionality provided by each subsystem of the TSF.
(maybe pam does this, rsbac and selinux does this,
others don't I'm afraid)
ADV_HLD.2.5C The high-level design shall identify any underlying
hardware, firmware, and/or software required by the TSF
with a presentation of the functions provided by the
supporting protection mechanisms implemented in that
hardware, firmware, or software.
(the identification is done in the dependencies. the
presentation of supporting protection mechanisms is
very rare.)
ADV_HLD.2.6C The high-level design shall identify all interfaces to the
subsystems of the TSF.
(back to man pages. I think it is in better shape than the
other parts)
ADV_HLD.2.7C The high-level design shall identify which of the
interfaces to the subsystems of the TSF are externally visible.
(if the interfaces are described, it most probably does)
ADV_HLD.2.8C The high-level design shall describe the purpose and method
of use of all interfaces to the subsystems of the TSF, providing
details of effects, exceptions and error messages, as
appropriate.
(some do, some don't)

ADV_IMP.2 Implementation of the TSF (EAL5)
(Yes, we are good at it. This is what open source is about.)
ADV_IMP.2.1D   The developer shall provide the implementation
representation for the entire TSF.
(Use the source, Luke!)
ADV_IMP.2.1C   The implementation representation shall unambiguously
define the TSF to a level of detail such that the TSF can be
generated without further design decisions.
(run debuild, and do not think even a bit:)
ADV_IMP.2.2C   The implementation representation shall be internally
consistent.
(It would not compile othervise. Okay, some packages need
code cleanup.)
ADV_IMP.2.3C   The implementation representation shall describe the
relationships between all portions of the implementation.
(The Depends: et al control fields)

ADV_IMP.3, which is EAL7, is more with:
ADV_IMP.3.4C The implementation representation shall be structured into
small and comprehensible sections.
(I don't know if having several packages or having 

Re: Debian Enterprise - a Custom Debian Distribution

[Toens Bueker]

David B Harris <[EMAIL PROTECTED]> wrote:

>> And I think I have the structure to make this work. I'm
>> writing now, should have something for you later today.
> 
> Sorry, yeah. I should instead have said "*their*
> company", not any one company. The company they buy
> their hardware and support from. In my mind, HP and IBM
> are paramount, since they also happen to be the only two
> major suppliers for the shop I work in :)

For Germany Fujitsu-Siemens Computers (FSC) would be
another "target". Although they are officially supporting
SuSE and RH only, they have been very helpful in "porting"
their system management stuff (e. g. snmp agents) to
Debian. 

by
Töns 
-- 
There is no safe distance.

Re: Backport of the integer overflow in the brk system call

[Andreas Metzler]

Tom <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 02, 2003 at 10:08:03AM +0100, Andreas Metzler wrote:

>> Apparently nobody knew it was comparable to ptrace, it looked like a
>> simple bugfix and not like a local root exploit.

> Well, I just downloaded 2.4.23 from kernel.org and installed it.

You could have simply used the fixed 2.4.18 from security.debian.org.

[...]
> Was this problem a deviation from well-established security practices or 
> is a new thing? 

Afaict no and no.

> Could somebody explain it in a nutshell?

Afaik: 2.4.23 contains literally 100s of changes, one of these was a
small change to do_brk(), which looked like a normal non-critical
bugfix to everybody involved. Some time later Debian was hacked and
backtracing how the intruder got superuser privileges revealed that
that the do_brk() without the "small change" was guilty, it had been
no simple bug but a local privilege escalation issue.

To repeat this: Neither Debian, nor Suse, nor Linux Kernel had known
that there was a local root exploit in Linux Kernel 2.4.x (x<<23)
until Debian was hacked *and* until Robert van der Meulen found out
how the intruder managed to get root privileges on the hacked
machines.

Once the vulnerability was known at least Debian and RedHat (I don't
read e.g. Suse's or Mandrake's security announces) released an
advisory with fixed packages as fast as possible.

Disclaimer: I am no member of the security team and was not involved
in finding or fixing the bug.
   cu andreas
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Joey Hess <[EMAIL PROTECTED]> writes:

> John Goerzen wrote:
> > Please check out the debsigs package.  I wrote it when I worked at
> > Progeny back in 2001, and Branden Robinson maintains it these days.  It
> > does exactly that.
> 
> Unfortunatly, the method debsigs uses to add the signature to the .deb
> provuces a file that apt (including apt-ftparchive) does not consider to
> be a debian package. This makes it kind of hard to upload the result to
> the debian archive. :-(

I tried it out and the problem is in the pre-configuring of packages
with debconf. More to the point apt-extracttemplates can't handle the
difference between an dpkg-deb and ar created ar archive (ar has a
trailing '/' after the filename).

I submitted a one line patch to apt to fix this and behave like
dpkg. I hope this gets added soon. Till then its either signed debs or
pre-configuring of packages.

> I filed bugs about this a long time ago, it is apparently blocked
> waiting on the mythical dpkg 2.0 which is supposed to have its own
> external ar program that generates more valid debs. See the bugs of apt,
> dpkg, and/or debsigs (I forget which, and am offline) for details.
> 
> I'm *sure* there is some way around it that does not involve waiting on
> dpkg 2.0, of course, if someone has the energy to work on it.

dpkg-deb could be patched to support modifying debs and debsigs could
be changed to use that instead of using ar. Or debsigs could modify
the ar archive directly without forking ar. There is an CPAN ar module
which could be used. I'm not sure if it uses a trailing '/' too but if
so that would be simple to copy and fix.

Another but not so nice way wouldbe for all signed debs to conflict
with apt-utils.

MfG
Goswin

Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)

[Goswin von Brederlow]

Eduard Bloch <[EMAIL PROTECTED]> writes:

> Moin Goswin!
> Goswin von Brederlow schrieb am Tuesday, den 02. December 2003:
> 
> > > I would like to see the following things happen:
> > > 
> > >  - current md5sums file in control.tar.gz should contain
> > >checksums of really all files
> > >  - a signature of the md5sums file should be stored either in
> > >control.tar.gz or in the ar file itself
> > >  - new dpkg version should pickup the signature files and store them
> > >either in /var/lib/dpkg/info or in some alternative directory
> > >  - modify debsums to check the signature as well as maintainer scripts'
> > >checksums
> > > 
> > > Any additions, comments, etc.?
> > 
> > If you think files of a deb are compromised on your system what makes
> > you thing the md5sum files are not? Storing the md5sum files on-site
> > will only help against accidental (or stupid) changes.
> 
> Because you store the extra signatures of md5sum files in a separate
> location, as said above. But as Goswin and other stated before, the gain
> (securitywise) is low compared to the costs of extra signing and
> handling with the signature file. So I see another good method to verify
> the already installed files: create an extended version of the current
> Contents-ARCH files including the md5 checksums of each file from each
> package and sign this Md5Contents file with some official key.

That would be signed automatically every day. A compromised master
would make the file useless.

> > Also since the complete deb is just as save as the md5sumsfile
> > contained in the deb it is pointless to have such. People who realy
> > want to store the md5sums file should create it during install time
> > (let dpkg do that). The md5sums file still requires one to download
> 
> As said before, some people may not run tripwire&Co. during the initial
> installation and enable such modification detection systems later. There
> should be a way to feed the database with known good md5sums afterwards,
> see above.
> 
> > the complete deb from a trusted source to verify the installed
> > system. But then why not just do a 1:1 compare?
> > 
> > After all this ranting about how useless a md5sums file is here's an
> > idea:
> > 
> > 1. No md5sums files are contained in the deb itself.
> 
> You mean in the deb as created by dpkg-deb during the build? Okay, the
> functionality may be moved to the second step (below), but then
> dh_md5sums should be converted to a dummy script and debhelper conflict
> with the older versions of dpkg-dev.

The existance of the file wouldn't hurt but making dh_md5sums a dummy
would be the upgrade path.

> > 2. dpkg-genchanges unpacks the deb (control and data) and creates a
> >sorted md5sums file (sorted by md5sum, by filename or whatever. But
> >reproducible). A signature of the md5sums file (md5sum of it?) is
> >then added to the change file.
> 
> As we agreed on IRC, the contents of control.tar.gz should be included
> too. Idealy extracted temporarily into
> $tmpdir/var/lib/dpkg/info/pkgname.FILE so debsums gets full paths and
> has easy job later.

Another point mentioned on irc was that the original conffiles all
need to be preserved, at least the md5sum of each. When recreating the
md5sums file for verification purposes (if it's not created and stored
at install time) would have to have the original md5sums of all
conffiles or too many false positives would appear.

Comparing local conffiles against the original ones would be a local
matter and another step in auditing. Having the actual original
conffiles around for that would be better than just saying "was
modified" after comparing md5sums. For that reason (and for three way
diffs on updates) I would like dpkg to allways create a
conffile.dpkg-orig even when first installing. Alternatively a
/var/lib/dpkg/info/package.conffiles/ directory could be used to store
original conffiles or /usr/share/doc/package/example.conffiles/.

MfG
Goswin

Re: [custom] Debian Enterprise - a Custom Debian Distribution

[Zenaan Harkness]

On Tue, 2003-12-02 at 11:05, Enrico Zini wrote:
> On Mon, Dec 01, 2003 at 02:33:57PM -0600, Chad Walstrom wrote:
> 
> > >  - GNU ERP software project ?name?
> > GNU Enterprise (gnue)  http://www.gnue.org/
> 
> I've just learnt of Cubit from South Africa: http://www.cubit.co.za/

Thank you very much. Added to website.
Zenaan

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: Bits from the RM

[Anthony Towns]

On Tue, Dec 02, 2003 at 10:34:26AM +0200, Antti-Juhani Kaijanaho wrote:
> That said, it has been too long since I last looked at grep-dctrl.  I'll
> try to fix that "in a couple of days" :)  I can only say that my
> teaching duties have exhausted me during the autumn.

And hey, if you manage to fix it in anything approaching "a couple of
days", you'll be able to upload it at the next *possible* moment. Go you!

Cheers,
aj


-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   Linux.conf.au 2004 -- Because we can.
   http://conf.linux.org.au/ -- Jan 12-17, 2004

Re: Debian Enterprise - a Custom Debian Distribution

[Alexander Kitzberger]

Hello Töns,
we are trying to get the Siemens ServerView ported to debian.
After I read your message. I think you may have contact to FSC?
Or may be this software is already ported?
Do you have some more information for me?
Thank you in advance
best regards
Alex
Toens Bueker schrieb:
David B Harris <[EMAIL PROTECTED]> wrote:

And I think I have the structure to make this work. I'm
writing now, should have something for you later today.
Sorry, yeah. I should instead have said "*their*
company", not any one company. The company they buy
their hardware and support from. In my mind, HP and IBM
are paramount, since they also happen to be the only two
major suppliers for the shop I work in :)

For Germany Fujitsu-Siemens Computers (FSC) would be
another "target". Although they are officially supporting
SuSE and RH only, they have been very helpful in "porting"
their system management stuff (e. g. snmp agents) to
Debian. 

by
Töns 

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Joey Hess ([EMAIL PROTECTED]) [031202 02:55]:
> > Goswin von Brederlow wrote:
> > > What can we do with deb signatures?
> > > 
> > > For our current problem, the integrity of the debian archive being
> > > questioned, the procedure would be easy and available to every user:
> > > 
> > > 1. get any clean Debian keyring (or just the key signing the keyring)
> > > 2. verify the latest Debian keyring
> > > 3. verify that each deb was signed by a DD and the signature fits
> 
> > The canoical attack against signed debs in this situation is to find a
> > signed deb on snapshot.debian.net that contains a known security hole.
> 
> To avoid this attack, it is necessary that the filename of the deb or
> the version of the package is also signed.

% dpkg -e moon-buggy_0.5.53-5.0.0.1_i386.deb t
% cat t/control 
Package: moon-buggy
Version: 0.5.53-5.0.0.1
Section: games
Priority: optional
Architecture: i386
Depends: libc6 (>= 2.3.2.ds1-4), libncurses5 (>= 5.3.20030510-1), debconf
Conflicts: moon-buggy-esd, moon-buggy-pause, suidmanager (<< 0.50)
Installed-Size: 232
Maintainer: Christian T. Steigies <[EMAIL PROTECTED]>
Description: Drive some car across the moon
 Moon-buggy is a simple character graphics game, where you drive some
 kind of car across the moon's surface.  Unfortunately there are
 dangerous craters there.  Fortunately your car can jump over them!

Since the control file would be signed its all there. You just have to
verify the verions apt things its using against what the control file
says. That can be added to apt through
/etc/apt/apt.conf.d/10-verify-debsigs which I'm experimenting with at
the moment.

I wrote a trivial fix for apt-utils to support debsigs signed
debs. Without it one gets a strange error message about corrupt debs
and the pre-configuring of packages fails but everything works in the
end.


I'm not sure how an upgrade path should look. A drastic upgrade path
could make all signed debs Conflict with older apt-utils. People
using sarge/sid debs on potato/woody would get apt-utils removed,
which doesn't hurt. Everyone else would get an update. That would mean
we can introduce signed debs in sarge but have to live with every deb
conflicting with older apt-utils for the next 4 years.

Packages could drop the Conflict if one of the packages they depend on
have it. Pretty much all binaries have a versioned depend on libc6,
that would take care of most debs.


A slower upgrade path would be to fix apt now for sarge, allow debsigs
signed debs for sarge+1 for non core packages, and make them mandatory
for sarge+2.


A slightly dirty upgrade path would be to ignore apt-utils breakage
for older releases, fix apt-utils in sarge and start using debsigs
signed debs for sarge. apt-utils is not important to maintain or
update a debian system so to hell with it. :)

MfG
Goswin

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Tom <[EMAIL PROTECTED]> writes:

> On Tue, Dec 02, 2003 at 11:07:53AM +0100, Andreas Barth wrote:
> > * Joey Hess ([EMAIL PROTECTED]) [031202 02:55]:
> > > Goswin von Brederlow wrote:
> > > > What can we do with deb signatures?
> > > > 
> > > > For our current problem, the integrity of the debian archive being
> > > > questioned, the procedure would be easy and available to every user:
> > > > 
> > > > 1. get any clean Debian keyring (or just the key signing the keyring)
> > > > 2. verify the latest Debian keyring
> > > > 3. verify that each deb was signed by a DD and the signature fits
> 
> What precautions are taken that the DD actually signed it with the DD's 
> private key?  After all this compromise was due to a DD's machine being 
> compromised.  I don't think you can audit every DD's workstation to make 
> sure the keys are well managed.
> 
> Set aside the possibility that the DD herself is actually the attacker.  
> You have to have an answer for these remote possibilities.  (Things tend 
> to get maximally bad).

You never can. But once the compromise or the DD is found out it would
be easy to scan the archive for possible compromised packages audit
the sources and rebuild the binaries.

Nothing prevents an attacker from uploading sources with backdors now
once he has the private key and passphrase of the maintainer which
would be far worse than uploading a compromsed binary.

> > > The canoical attack against signed debs in this situation is to find a
> > > signed deb on snapshot.debian.net that contains a known security hole.
> > 
> > To avoid this attack, it is necessary that the filename of the deb or
> > the version of the package is also signed.

The control file is which holds all the information. The filename is
irelevant (my d-i images have filenames without version infromation
for example).

MfG
Goswin

UserLinux white paper

[Bruce Perens]

I did a first pass at the UserLinux white paper, it's at
http://userlinux.org/white_paper.html. I think I'll sleep for a while.

Thanks

Bruce

OOPS!: Re: UserLinux white paper

[Bruce Perens]

That's userlinux.com . I don't have the .org, some domain squatter has
that.

Thanks

Bruce

On Tue, Dec 02, 2003 at 12:04:31PM +, bruce wrote:
> I did a first pass at the UserLinux white paper, it's at
> http://userlinux.org/white_paper.html. I think I'll sleep for a while.
> 
>   Thanks
> 
>   Bruce

-- 
--
Bruce Perens [EMAIL PROTECTED] 510-526-1165
Perens LLC / 1563 Solano Ave. / PMB 349 / Berkeley CA 94707 / USA

Re: Revival of the signed debs discussion

[Tom]

On Tue, Dec 02, 2003 at 01:17:58PM +0100, Goswin von Brederlow wrote:

> Tom <[EMAIL PROTECTED]> writes:
> > What precautions are taken that the DD actually signed it with the DD's 
> > private key?
> > Set aside the possibility that the DD herself is actually the attacker.  
> 
> You never can. But once the compromise or the DD is found out it would
> be easy to scan the archive for possible compromised packages audit
> the sources and rebuild the binaries.

Thanks for the frankness; I was asking the question pointedly.  But if 
you fix the problem after it occurs, the damage is done.

Closed source companies have ways of dealing with social engineering 
aspects (people wear badges; secure sources on isolated networks, 
security guards, threats of firing people, smart cards for SSH/VPN).

I worked at Microsoft for 3 years and did some work with the security 
guys.  The main branch of NT is about 70gb.  They have a policy that any 
code has to be on encyrpted file system.  If your laptop gets stolen 
with NT code on it, you get fired.  If you leave your laptop in your car 
or check it on your airplane, you get fired.)

The point of my question is: what can open source do that is comprable?  
It seems especially relevant considering the other thread about 
establishing Enterprise Debian.

My nagging is just to provoke thought in the community.  I don't have 
any answers.

Re: Debian Enterprise - a Custom Debian Distribution

[Toni Mueller]

Hello,

On Tue, Dec 02, 2003 at 09:53:19AM +1100, Zenaan Harkness wrote:
> On Tue, 2003-12-02 at 07:31, David B Harris wrote:
> > who run it, as is so often the case these days. I can't count the number
> > of times I've heard horror stories from HP customers (and other vendors
> > as well) about people being unable to RMA hardware because they're using

fully agreed :-(

> BTW, what's RMA stand for?

It stands for "Return Material Authorization" and means that you get a
number to stick on your broken hardware you want to ship back to the
vendor for repair.

If you're running something not included when you bought it, or on a
usually very short compatibility list, then most vendors I've
encountered so far are _very_quick_ to tell you that you broke the
hardware because you used non-approved software, and/or that you need
to verify first if your hardware is also broken under their
pre-installed crap, and file a bug stating the kind of breakage with
their pre-installed software (usually).


Best,
--Toni++

Re: [debian enterprise] sub-project planning

[cobaco]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2003-12-01 19:12, Andres Salomon wrote:
> d-i enhancements might include installation types (similar to redhat's
> installer; select server, workstation, etc, and have packages selected
> for you), support for enterprise features directly in the installer

We have these in Skolelinux, so you might want to take a look at that (see 
http://developer.skolelinux.no/cgi-bin/viewcvs.cgi/skolelinux/src/
base-config-skolelinux)

- -- 
Cheers, cobaco
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/zIc55ihPJ4ZiSrsRAkVvAJ9VhWKHs1tWOa23cBbu0v1SyqXTfACfd6SM
Y+3UtqC75jemEkTxYzE8QPQ=
=FgCt
-END PGP SIGNATURE-

Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)

[Bernhard R. Link]

* Chad Walstrom <[EMAIL PROTECTED]> [031201 22:28]:
> md5sums and signatures are most useful in the context of installation.
> Post-installation, you cannot be guaranteed that an intrusion rootkit
> doesn't compromise the md5sum files themselves. Using the installed
> *.md5sum files to check the integrity gives you a false sense of
> security unless those *.md5sum files are signed or CRC'd as well.

Someone using those md5sums stored there is comparable to someone using
the local md5sum utility or checking things from with the installed
kernel running.

> A true IDS is needed, such as aide, tripwire, or cfengine to detect
> post-installation intrusion.  Tie in aide or tripwire database
> checks/updates with the apt.conf "PostInst" option in addition to a
> daily cronjon to ensure the database is updated in a timely manner.

I think this is even more stupid than using *.md5sums. When they are
daily generated, you have no chance at all to be sure they are not
modified.

Hochachtungsvoll,
  Bernhard R. Link

-- 
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Tom <[EMAIL PROTECTED]> writes:

> On Tue, Dec 02, 2003 at 01:17:58PM +0100, Goswin von Brederlow wrote:
> 
> > Tom <[EMAIL PROTECTED]> writes:
> > > What precautions are taken that the DD actually signed it with the DD's 
> > > private key?
> > > Set aside the possibility that the DD herself is actually the attacker.  
> > 
> > You never can. But once the compromise or the DD is found out it would
> > be easy to scan the archive for possible compromised packages audit
> > the sources and rebuild the binaries.
> 
> Thanks for the frankness; I was asking the question pointedly.  But if 
> you fix the problem after it occurs, the damage is done.
> 
> Closed source companies have ways of dealing with social engineering 
> aspects (people wear badges; secure sources on isolated networks, 
> security guards, threats of firing people, smart cards for SSH/VPN).
> 
> I worked at Microsoft for 3 years and did some work with the security 
> guys.  The main branch of NT is about 70gb.  They have a policy that any 
> code has to be on encyrpted file system.  If your laptop gets stolen 
> with NT code on it, you get fired.  If you leave your laptop in your car 
> or check it on your airplane, you get fired.)
> 
> The point of my question is: what can open source do that is comprable?  
> It seems especially relevant considering the other thread about 
> establishing Enterprise Debian.
> 
> My nagging is just to provoke thought in the community.  I don't have 
> any answers.

We keep the source on millions of different computers worldwide with
different levels of security, different operating systems, different
cpus (an exploit for i386 won't work on m68k directly) and the code is
read again and again by countless people. You can't compromise all
copies of the source.

Also its impossible to slip code into any common open source project a
just one end (say compromise cvs.debian.org and slip a change in)
without getting several people to notice and read the changes
made. You might get away with it for a few days (depending on how
active the project is) but someone will notice the change no matter
how clever you think you are.

There is no security as strong as many people reading the source over
and over. You can't hack their brains to skip over the backdoor code
and you can only obfuscate a backdoor so much.

MfG
Goswin

Re: Revival of the signed debs discussion

[Tom]

On Tue, Dec 02, 2003 at 02:20:43PM +0100, Goswin von Brederlow wrote:

> There is no security as strong as many people reading the source over
> and over. You can't hack their brains to skip over the backdoor code
> and you can only obfuscate a backdoor so much.

Allright, allright, I'll cry uncle.

/me standing way over here on the outside sure is noticing a lot of 
ruckus for something that isn't a problem :-)

Re: Bits from the RM

[Mark Howard]

On Tue, Dec 02, 2003 at 06:56:13PM +1100, Brian May wrote:
> A release critical bug in one package could be caused by a non-release
> critical bug in another package.

How?
If the bug is caused by a problem in another package then it should be
reassigned (and more importantly fixed). The bug is still RC, even if it
only affects dependent packages

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 

Re: apt-rpm article -- the features we don't have

[Joey Hess]

A.J. Rossini wrote:
> Maybe I'm missing something, but none of this sounds like
> functionality that a bit of parsing  out to other programs can't
> solve, given that I do it locally for the systems in my lab.
> 
> Joey Hess <[EMAIL PROTECTED]> writes:
> 
> > Interesting article on LWN: http://lwn.net/Articles/60650/ (subscription
> > required) In summary, apparently apt-rpm users can now do some things
> > with apt that we cannot.
> >
> > To install a package directly, with apt downloading any necessary
> > dependencies:
> >   apt-get install rpmver-2.0-13498cl.i386.rpm
> 
> couldn't this just refer to dpkg --install ?

dpkg does not download deps of the package. At best with dpkg and our
apt it is a three step process.

> > Similarly, to check the build depends of a source package file:
> >   apt-get build-dep apt-listchanges-1.49-11104cl.src.rpm
> 
> similarly...?

Nope, this is impossible to do with our apt unless you set up a
repository and add your sources to it. Of course dpkg-checkbuildeps can
be used if you unpack the source.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: apt-rpm article -- the features we don't have

[Jonathan Dowland]

On Mon, Dec 01, 2003 at 11:17:26PM -0800, A.J. Rossini wrote:
> 
> Andrew Pollock <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Dec 01, 2003 at 07:50:29PM -0800, A.J. Rossini wrote:
> >> 
> >> Joey Hess <[EMAIL PROTECTED]> writes:
> >> 
> >> >
> >> > To install a package directly, with apt downloading any necessary
> >> > dependencies:
> >> >   apt-get install rpmver-2.0-13498cl.i386.rpm
> >> 
> >> couldn't this just refer to dpkg --install ?
> >
> > But that won't satisfy any dependencies that the package you're installing
> > has.
>
> Got it -- a bit more than just parsing out... but suprisingly little
> (other than someone's time, which is always worth a great deal...)

This would be a useful feature indeed.

(assembling this message was a nightmare, please read
http://www.river.com/users/share/etiquette/#inline)

-- 
Jon Dowland
http://jon.dowland.name/

Re: Revival of the signed debs discussion

[John Goerzen]

On Tue, Dec 02, 2003 at 11:07:53AM +0100, Andreas Barth wrote:
> > The canoical attack against signed debs in this situation is to find a
> > signed deb on snapshot.debian.net that contains a known security hole.
> 
> To avoid this attack, it is necessary that the filename of the deb or
> the version of the package is also signed.

The filename is pretty much irrlevant to tools everywhere; I don't see
any benefit in mucking with that.  Besides, it can get altered along the
way.

Since the version of the package is part of the control file, and
debsigs signs the control data along with the package contents, the
version is already protected by debsigs.

-- John

Re: Bits from the RM

[Javier Fernández-Sanguino Peña]

On Mon, Dec 01, 2003 at 02:45:09PM +1000, Anthony Towns wrote:
> Hello world,

Hello aj.

>* LSB 1.3 compatibility mostly achieved
> 
>  (LSB non-compliance issues are now Release Critical; bugs
>   should be filed and addressed by the LSB team, which hangs
>   around the debian-lsb mailing list. Only one compliance
>   issue remains unfixed in sid. LSB 2.0 compliance will be
>   trickier, but will hopefully be being worked on well before
>   the next release.)

Just a note (and please bear in mind that I'm a LSB novice):

I just noticed that lsbdev has a number of outstanding bugs and is not 
updated to the latest upstream release (1.3) as described in #188955 and
#221287. Even if it's not in testing, and thus not a RC problem per se, 
could the LSB team please help the maintainer upgrade to a new version?
(which would probably fix #194986, #179986, #218081)

Thanks

Javi



signature.asc
Description: Digital signature

Re: apt-rpm article -- the features we don't have

[Jonathan Dowland]

On Mon, Dec 01, 2003 at 07:06:41PM -0500, Joey Hess wrote:
 
> Similarly, to check the build depends of a source package file:
>   apt-get build-dep apt-listchanges-1.49-11104cl.src.rpm

Should this be the job of apt-get? Fetching a list of build-depends is a
similar job to that performed by apt-cache for other fields. I always
associate apt-get with installing and removing packages. (now that I
think about it, apt-get remove reads a bit like 'click on start to shut
down your computer').

-- 
Jon Dowland
http://jon.dowland.name/

Re: Backport of the integer overflow in the brk system call

[Jonathan Dowland]

On Tue, Dec 02, 2003 at 12:08:17PM +0100, Andreas Metzler wrote:
 
> Afaik: 2.4.23 contains literally 100s of changes, one of these was a
> small change to do_brk(), which looked like a normal non-critical
> bugfix to everybody involved. Some time later Debian was hacked and
> backtracing how the intruder got superuser privileges revealed that
> that the do_brk() without the "small change" was guilty, it had been
> no simple bug but a local privilege escalation issue.

Thanks Andreas!

My understanding is that the do_brk vulnerability allowed access to kernel
address space. It seems a lot of work is needed to move from that freedoom to
spawning a root shell. I'd be interested in seeing a worked example.   

-- 
Jon Dowland
http://jon.dowland.name/

Re: Bits from the RM

[Sam Hartman]

> "aj" == Anthony Towns  writes:

aj> or overloaded with work, or, for that matter, fixing compromised Debian
aj> servers -- do you think it's desirable and possible to:

aj> * for confirmed bugs with a known fix, upload a fixed package
aj>   within a day or two of the patch been sent to the bug log

No, I don't think it is always desirable to do this and certainly my
maintinance style doesn't work well with this methodology.  The
problem is there is a fairly high fixed cost to building, testing and
doing release management for a package.  It takes me about an
afternoon to do a PAM or OpenAFS release even if I change one line.
OK, for a one line change I can probably get that down to two hours or
so.

It's a lot easier for me if I batch bugs together and if I did not do
so, I'd be even more behind than I already am.

I certainly think that expediting package uploads for RC bugs is a
critical responsibility I as a maintainer have.


But even if someone else claims to have tested a bug, I'm going to be
the one signing the package; I'm taking responsibility.  So I must
spend the time necessary to understand the fix, confirm the fix and do
the release engineering cruft I do for every release.

Clearly this can be taken too far; pam is an excellent example of a
package where I've let things slip enough that I'm having difficulty
digging myself out of the hole.

But I think dealing with normal bugs with confirmed fixes in a month
or two is much more reasonable than a day or two.  I'd feel
differently if Debian was my primary job or if I found a style of
maintaining packages that worked well for me with this goal.

Re: Revival of the signed debs discussion

[Joey Hess]

Goswin von Brederlow wrote:
> > dpkg that it is downgrading the package, and a clever attacker might
> > avoid even that.
> 
> How would you avoid it?

Make the replacement package really be a different package entirely, of
a higher version than the package it purports to replace.

I think aj had some more examples along these lines the last time this
came up.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Backport of the integer overflow in the brk system call

[Isaac To]

> "Jonathan" == Jonathan Dowland <[EMAIL PROTECTED]> writes:

Jonathan> On Tue, Dec 02, 2003 at 12:08:17PM +0100, Andreas Metzler
Jonathan> wrote:
>> Afaik: 2.4.23 contains literally 100s of changes, one of these was a
>> small change to do_brk(), which looked like a normal non-critical
>> bugfix to everybody involved. Some time later Debian was hacked and
>> backtracing how the intruder got superuser privileges revealed that
>> that the do_brk() without the "small change" was guilty, it had been
>> no simple bug but a local privilege escalation issue.

Jonathan> My understanding is that the do_brk vulnerability allowed
Jonathan> access to kernel address space. It seems a lot of work is
Jonathan> needed to move from that freedoom to spawning a root
Jonathan> shell. I'd be interested in seeing a worked example.

Actually I'm staring at the code for hours without much success about how to
write anything in the kernel.  It does not literally allow access to the
kernel address space: if it does so, all you need to do is to traverse the
kernel data structures to find where is the task_struct for the process
itself and change the EUID to 0 in order to get root.  What the bug gives is
a memory region that extends through the kernel memory.  The process cannot
access that region: it is protected, and you can read it only in kernel
mode.  You cannot try to pass that as an address buffer to a system call
either: system calls check whether address is past the end of process
address space.  So the program must somehow trick the kernel into accessing
the region by itself, and since the kernel believes the correctness of the
region it will not do any further checking.  The only way that readily comes
to mind is to let the program core dump: the kernel will most likely happily
read all the kernel memory and save it into the core file.  But it is still
rather far from changing anything in the kernel memory.  Andreas is
definitely right that the hole doesn't look like that it is that dangerous.

Regards,
Isaac.

Re: Revival of the signed debs discussion

[Henning Makholm]

Scripsit Goswin von Brederlow <[EMAIL PROTECTED]>

> There is no security as strong as many people reading the source over
> and over. You can't hack their brains to skip over the backdoor code
> and you can only obfuscate a backdoor so much.

I refer you to Ken Thompson's Turing award lecture. If someone who
really means business manages to compromise binary toolchain debs, all
the hackers in the world reading source over and over will not find
the backdoor.

(And "toolchain" here includes all code that is even marginally
involved in the process leading to itself being recompiled. Libc,
kernel images, lilo, dpkg, debhelper, perl, etc etc).

-- 
Henning Makholm   "No one seems to know what
   distinguishes a bell from a whistle."

ITP: konversation -- User friendly Internet Relay Chat client for KDE (fwd)

[Nathaniel W. Turner]

[It looks like the x-debbugs-cc part of bugs.d.o is not working atm (nor is 
the index page for wnpp showing new bugs), so I'm resending this message to 
pertinent lists.  I know the upload queue is down due the hack, but it would 
probably be good to make this ITP known so we don't get several duplicates.  
I also need to find a sponsor.  =)  -nate]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-kde@lists.debian.org

* Package name    : konversation
  Version         : 0.13
  Upstream Author : Dario Abatianni <[EMAIL PROTECTED]> et al.
* URL             : http://konversation.sourceforge.net/
* License         : GPL
* Description : User friendly Internet Relay Chat client for KDE

 Konversation is a client for the Internet Relay Chat (IRC) protocol.
 It is easy to use and well-suited for novice IRC users, but novice
 and experienced users alike will appreciate its many features:
 .
   * Tabbed channel and server windows
   * IRC color support
   * Pattern-based message highlighting and OnScreen Display
   * Multiple identity support
   * Powerful, multi-language scripting support (with DCOP)
   * Customizable command aliases
   * NickServ-aware logon (for registered nicknames)
   * Smart logging
   * Traditional or enhanced-shell-style nick completion
   * DCC resuming

I have been maintaining CVS snapshot packages of this program for a month or 
so now, primarily for my own entertainment.  However, when asked recently 
about uploading a stable release to Debian, I realized that this was only 
logical.  So here I am.

This package is lintian and linda* clean.

If anyone wants to co-maintain, I'm happy to share or help or whatever.

The package I propose uploading is at the following repository:

deb http://debian.houseofnate.net/ unstable proposed
deb-src http://debian.houseofnate.net/ unstable proposed

The latest version of the debian directory can also be browsed at my 
Subversion repository:
http://svn.houseofnate.net/pkg-konversation/branches/stable/

Comments and criticism are most welcome.  =)

Cheers,
nate

P.S. If anyone wants to sponsor me for this package, please let me know.  I 
have tried to make the .diff.gz as clean as possible for your reviewing 
pleasure.  =)


*I get a warning "W: konversation; Script ./usr/share/doc/konversation/
examples/dcop-away.sh is not executable.", but I think this is safe to 
ignore.  [2003-12-02: I have since made this warning go away.]

-- 
Nathaniel W. Turner
http://www.houseofnate.net/
Tel: +1 508 579 1948 (mobile)

Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)

[Chad Walstrom]

On Tue, Dec 02, 2003 at 02:01:23PM +0100, Bernhard R. Link wrote:
> > A true IDS is needed, such as aide, tripwire, or cfengine to detect
> > post-installation intrusion.  Tie in aide or tripwire database
> > checks/updates with the apt.conf "PostInst" option in addition to a
> > daily cronjon to ensure the database is updated in a timely manner.
> 
> I think this is even more stupid than using *.md5sums. When they are
> daily generated, you have no chance at all to be sure they are not
> modified.

I'm not following your logic, if that's what you call it.  You're saying
that checking the current filesystem on a daily basis is NOT a good way
to verify filesystem integrity?

Update your system when you introduce a known change (a must).  Check it
daily (a must).  What is incorrect about this policy?

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgpHEmhCfxdqF.pgp
Description: PGP signature

Re: apt-rpm article -- the features we don't have

[Matt Zimmerman]

On Mon, Dec 01, 2003 at 07:06:41PM -0500, Joey Hess wrote:

> Interesting article on LWN: http://lwn.net/Articles/60650/ (subscription
> required) In summary, apparently apt-rpm users can now do some things
> with apt that we cannot.

This has been true for some time; merging the applicable parts of the
apt-rpm tree is already on my todo list for post-sarge (#207400), after
integration of Release file signature verification (#203741).

-- 
 - mdz

Re: apt-rpm article -- the features we don't have

[Matthias Urlichs]

Hi, Joey Hess wrote:

> Of course dpkg-checkbuildeps can
> be used if you unpack the source.

So, giving a .dsc to dpkg-checkbuildeps shouldn't be any more work than
"skip the GPG armor, if present".

Unless I am overlooking something, of course.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
The total accumulated knowledge of all the men that ever walked the Earth on the
topic of women can fit in the period at the end of this sentence.

Re: Backport of the integer overflow in the brk system call

[Tom]

On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote:
> rather far from changing anything in the kernel memory.  Andreas is
> definitely right that the hole doesn't look like that it is that dangerous.

It messed up your life for a couple weeks.

Jesus, it's not the end of the world, but that's the way Microsoft (used 
to | still) thinks.

If it wasn't a big deal we wouldn't be talking about it.  It shut down 
servers.  It's dangerous enough.

Re: Debian Investigation Report after Server Compromises

[Marc Haber]

[personal reply, and posting on -devel]

Hi Joey,

thanks for this report. I am aware that this is the result of tedious
work, and I really appreciate your efforts. Let me, however, ask a few
probably inconventient questions, and I surely hope that they won't be
ignored this time.

On Tue, Dec 02, 2003 at 03:23:51PM +0100, Martin Schulze wrote:
> Several methods based on different control data were used to verify
> the packages and to ensure that the archives weren't altered by the
> attacker:
> 
>  . externally stored lists of MD5 sums accumulated over the past weeks
>on not compromised machines
>  . digitally signed .changes files from external debian-devel-changes
>archives on not compromised machines
>  . digitally signed .changes files on the respective archive servers
>  . externally stored mirror log files

(1) Were checks done on completely all archives?
- main archive on auric, including package pool and potato
- non-US
- security

(2) Are more details on the checks available? For example, are the
scripts that were used available to the public? Against which
servers did you check?

(3) Since there currently seem to be gaps in archival of .changes
files, can you positively say that every single file in all archives
was verified for its integrity?

> On Wednesday, November 19th, at approximately 5pm GMT, a sniffed
> password was used to log into an unprivileged developer account on the
> host klecker (.debian.org).
> The same account and password data were then used to log into the
> machine master,
> The attacker then tried to get access to the host murphy with the same
> account.
> On the next day the attacker used a password sniffed on master to log
> into gluck, get root there and also install the SucKIT root-kit.

(4) Did the attacker try to get user or root access on other project
boxes, including auric? Were these access attempts successful?

(5) Were the other project boxes, including auric, swept for root-kits
as well? Which methods were used to determine the other boxes
being clean?

> The forensic analysis revealed exact dates and times when the program
> /sbin/init was overwritten and the root-kit installed.  The analysts
> also discovered the executable file which was used to gain root access
> on the machines, which was protected and obfuscated with Burneye.
> Upon unwrapping and disassembling the exploit, security experts
> discovered which kernel bug was utilised.

This is a pretty major and impressive achievement. My compliments on
being sucessful. Debian has proven again to be technically adept, I
really appreciate that.

> On klecker, however, this was postponed for a scheduled maintenance so
> the security archive could be brought online again sooner than the
> other services.  At that time we also didn't have console access to
> klecker, so recovery had to be done remotely.  After a disk-image was
> made via serial console login to a local machine on a firewalled
> network connection, the root-kit was removed, the kernel exchanged and
> hardened, binaries double-checked and the security archive verified
> against several different external sources.  This machine will be
> re-installed in the next few weeks.

While my rationality says that this procedure is fine, my gut feelings
are not comfortable with this.

(6) Did klecker run with a known good system (for example, booted from
a CD) while the binaries were verified?

(7) Wouldn't it be possible to move security.debian.org to a different
machine while klecker is reinstalled sooner than "in the next few
weeks"?

(8) Will you repeat the scrutiny on the security archive after
klecker's reinstallation? Do you keep reference data around so
that this scrutiny will be easier and faster?

> The secret GnuPG/PGP keys which were found on debian.org machines were
> also removed from the Debian keyrings and thus deactivated.

(9) This most probably includes the Keys that are used to automatically
sign Release files, right? Will new Debian Archive Automatic
Signing Keys be generated?

> Thanks
> 
>   . James Troup and Ryan Murray for their general work on all hosts
>   . Adam Heath and Brian Wolfe for their work on master and murphy
>   . Wichert Akkerman for his work on klecker
>   . Dann Frazier and Matt Taggart for their work on gluck
>   . Michael Stone and Robert van der Meulen for their forensics work
>   . Marcus Meissner for disassembling the used exploit
>   . Jaakko Niemi for his work on checking and re-enabling lists.debian.org
>   . Colin Watson for his work on checking and re-enabling bugs.debian.org
>   . Josip Rodin for his work on checking and re-enabling the lists web 
> archives

Let me say "Thank you" as well.

This announcement has greatly raised my trust in the project again,
and I really appreciate the openness. I hope that you will be able to
answer the questions I have raised.

Greetings
Marc

-- 
-

Re: debsums for maintainer scripts

[Thomas Viehmann]

Hallo.

Henrique de Moraes Holschuh wrote:
> Otherwise, it simply won't happen, unless about 90% of the packages or so
> aready use md5sums.  At that figure, you have some changes of passing a
> policy of 'must', and you are guaranteed to get a 'should' to be approved
> IMHO.
More than 92% of the packages already use md5sums. (600/7599 packages
don't.)
Still, I'm not a debian developer, so I'm not going to get anything passed.

Cheers

T.


pgpRigBy4lYo8.pgp
Description: PGP signature

Re: Revival of the signed debs discussion

[Wouter Verhelst]

Op ma 01-12-2003, om 14:34 schreef Goswin von Brederlow:
[...]
> Deb signatures method C:
> 
> And now for something completly different. A man with 3 noses. :)
> 
> Instead of keeping extra files with the signature of the deb the
> information could be stored inside the deb itself.
[...]

As much as I like this idea in principle, storing signatures inside
.debs has a serious problem: it won't work for us buildd maintainers.

As I explain in my document on wanna-build (usually at
http://people.debian.org/~wouter/wanna-build-states, but due to some
problems with that machine temporarily currently at
http://www.grep.be/wanna-build-states.html too), buildd maintainers do
not manually log in to their autobuilder to sign each and every .changes
on its hard disk; instead, they extract the .changes file from the mails
of successful messages sent to them (and to [EMAIL PROTECTED],
which processes them into what people can look up on
http://buildd.debian.org), sign that, and send it back. In reply, the
buildd will move all files mentioned in the .changes to an upload
directory for them to be uploaded. This results in quite a few mails
daily for me, being "just" the admin of 2 (out of 11) m68k autobuilders;
it must be a hell of a lot more for those such as Ryan Murray and James
Troup, who are and/or have been the sole autobuilder maintainers for
multiple architectures.

Requiring us to log in to the autobuilder to sign the .deb remotely is
not acceptable, for two reasons:
* it's way too much work for most of us
* it requires copying the secret key over, which is, uh, a bad idea.

An alternative would be to copy over the .debs, sign them on the local
hard disk, and upload them from there. That won't work either; it only
solves the second problem (as you don't have to copy the secret key
over), not the first, and it adds a bandwidth-related (if I have to
download all packages arrakis successfully builds, have to sign them
locally, and upload them again, I might exceed the download quota my ISP
has implemented; requesting a higher quota involves paying for it)

So unless you have a suggestion that would solve this particular issue,
I'm afraid this idea won't work in practice.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.



signature.asc
Description: Dit berichtdeel is digitaal ondertekend

Re: debsums for maintainer scripts

[Thomas Viehmann]

christophe barbe wrote:
> On Mon, Dec 01, 2003 at 08:24:09PM +0100, Thomas Viehmann wrote:
> 
>>Michael Ablassmeier wrote:
>>
>>>IMHO Lintian should also check if "dh_md5sums" is called and
>>>print at least a warning if this is not the case.
>>
>>In principle, I argree, but maybe it's better to check for the presence
>>of an md5sums file than to "force" (haha) people who don't like it to do
>>this.
>>Attached is a linda patch that does that. Maybe I'll post a link the
>>result of the run on my mirror later.
> What about checking the content of the md5sum file? 
I'd doubt that this is necessary. After all, not having an md5sum may
well be an oversight by the maintainer. But then, I'd probably adjust to
the preferences of the linda maintainer. (I haven't filed a wishlist bug
against linda yet.)

Cheers

T.


pgpGvgHnQzIOc.pgp
Description: PGP signature

Re: Bits from the RM

[Noah L. Meyerhans]

On Tue, Dec 02, 2003 at 05:09:37PM +1000, Anthony Towns wrote:
> > What happens if say there are simply not enough people interested in
> > GNOME for example, and the RC counts rise, and rise at an increasing
> > rate, and we never release again?
> 
> That's not a very interesting hypothetical -- there're plenty of people
> interested in getting Gnome to work on Debian. The aim is to focus
> on *fixing* the bugs, not remove the packages, and while threats can
> motivate sometimes (although they often do the opposite too), it's not
> really where we want to focus our attention or energies.

I agree that GNOME is not a very good example here.  Let me propose
another: The ARM port.  I realize the examples thus far have been in
regard to packages, not ports, but at what point does it make sense to
say "OK, the  port has held up the release of sarge by virtue of
not having a working installer.  It is going to be removed from the list
of supported platforms for sarge."

A quick look at
http://www.debian.org/devel/debian-installer/ports-status indicates
that, for some platforms, the situation is pretty grim.  ARM, for
example, hasn't been touched since March, and doesn't even have a
working kernel for the installer.  m68k is not a whole lot better, but
has at least seen some recent activity.

Where are the people who originally thought it would be "fun" to port
Debian to some of these architectures?  How long do we wait for them?
Clearly AJ's message to debian-devel-announce on August 19 announcing a
release goal of December 1 didn't inspire any new activity.  This gives
the appearance that the ARM port maintainers simply don't care if sarge
gets released at all.  This is very discouraging.

I don't want to come across sounding too harsh; I run Debian on a number
of architectures besides x86 and appreciate its multi-platform support.
But, if those who work on Debian on a given platform are no longer
interested in putting in the effort necessary to maintain that
architecture, we really should rethink our committment to it.

noah



pgpw6AT1yxzYE.pgp
Description: PGP signature

Re: Revival of the signed debs discussion

[Andreas Metzler]

Joey Hess <[EMAIL PROTECTED]> wrote:
> Goswin von Brederlow wrote:
>> > dpkg that it is downgrading the package, and a clever attacker might
>> > avoid even that.

>> How would you avoid it?

> Make the replacement package really be a different package entirely, of
> a higher version than the package it purports to replace.

> I think aj had some more examples along these lines the last time this
> came up.

I still don't understand how you change the version number (or the
package-name) without breaking the signature.
   cu andreas

Re: Revival of the signed debs discussion

[Thomas Viehmann]

Goswin von Brederlow wrote:
> Joey Hess <[EMAIL PROTECTED]> writes:

> I submitted a one line patch to apt to fix this and behave like
> dpkg. I hope this gets added soon. Till then its either signed debs or
> pre-configuring of packages.

>>I filed bugs about this a long time ago, it is apparently blocked
>>waiting on the mythical dpkg 2.0 which is supposed to have its own
>>external ar program that generates more valid debs. See the bugs of apt,
>>dpkg, and/or debsigs (I forget which, and am offline) for details.
The bug is #161593.
Appearantly, a fix had already been committed to CVS and then reverted
because it had not been determined whether "debs are ar files" actually
means "debs are ar files as those produced by the debian-supplied ar".

Good luck for your bug, but don't be disappointed if it suffers the same
fate.

Cheers

T.


pgpUXYAJMU5gI.pgp
Description: PGP signature

Re: Bits from the RM

[Wouter Verhelst]

Op di 02-12-2003, om 14:46 schreef Mark Howard:
> On Tue, Dec 02, 2003 at 06:56:13PM +1100, Brian May wrote:
> > A release critical bug in one package could be caused by a non-release
> > critical bug in another package.
> 
> How?

A program could use some library for most of its core operation, and
fail miserably because of a little bug in said library. This bug could
result in the entire package becoming useless, thus would be a grave
bug:

grave
makes the package in question unusable or mostly so, or causes
data loss, or introduces a security hole allowing access to the
accounts of users who use the package.

"grave" is an RC severity.

If that program would not use everything available in the buggy library,
it could be the case that the right severity for the bug against the
library would be either "important" or "normal"; consider the
possibility of a graphical library which does 3D rendering mostly, but
has the possibility of doing 2D graphics as well. A bug in the 2D
rendering bits of that library would not be grave (maybe not even
important) for that library, although it would certainly be valid to
file it as a grave bug against any package that only uses said library
for the 2D rendering possibilities. Since "important" and "normal" bugs
are not RC bugs...

(blatantly ignoring the fact that the RM and his team can choose to
ignore RC bugs, or make bugs RC if they're not really RC by themselves
here...)

> If the bug is caused by a problem in another package then it should be
> reassigned (and more importantly fixed).

Of course.

> The bug is still RC, even if it only affects dependent packages.

Not always.
-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.



signature.asc
Description: Dit berichtdeel is digitaal ondertekend

Re: Source only uploads? -- Survey evaluation

[Roland Stigge]

On Tue, 2003-12-02 at 02:41, Goswin von Brederlow wrote:
> Source only uploads were afaik disabled because the uploaded source
> would just disapear and never enter the archive afaik. It was just
> easier to block them than to fix the archive scripts I guess.

Just trying it (for fun, see package "spass" ;-), I didn't encounter any
problems. Wolfgang [1] could reproduce it (see the packages pages when
they are up again), but it was disabled some day afterwards.

bye,
  Roland

[1] http://lists.debian.org/debian-devel/2003/debian-devel-200310/msg01226.html


signature.asc
Description: This is a digitally signed message part

Re: Revival of the signed debs discussion

[Henrique de Moraes Holschuh]

On Tue, 02 Dec 2003, Wouter Verhelst wrote:
> So unless you have a suggestion that would solve this particular issue,
> I'm afraid this idea won't work in practice.

We could verify if the gpg agent (gpa? I forget the name...) cannot do this
over a secure channel. It should be able to, and if not, it can probably be
taught to.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Backport of the integer overflow in the brk system call

[Henning Makholm]

Scripsit Tom <[EMAIL PROTECTED]>
> On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote:

> > rather far from changing anything in the kernel memory.  Andreas is
> > definitely right that the hole doesn't look like that it is that dangerous.

> If it wasn't a big deal we wouldn't be talking about it.  It shut down 
> servers.  It's dangerous enough.

Whw Isaac said was that he understands why the kernel developer who
originally fixed the bug did not realize that it was security
critical.

-- 
Henning Makholm"Detta, sade de, vore rena sanningen;
 ty de kunde tala sanning lika väl som någon
 annan, när de bara visste vad det tjänade til."

Re: Source only uploads? -- Survey evaluation

[Andrew Suffield]

On Mon, Dec 01, 2003 at 10:09:34PM +0100, Roland Stigge wrote:
> Finally, the "decision" isn't just "technical".

Ah, the inevitable cry of the advocate of the technically inferior
approach.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Revival of the signed debs discussion

[Scott James Remnant]

No Cc was necessary, I am subscribed to debian-devel.

On Tue, 2003-12-02 at 03:30, Goswin von Brederlow wrote:

> Scott James Remnant <[EMAIL PROTECTED]> writes:
> 
> > A compromised dinstall on ftp-master could also replace the keyring
> > package with a new one containing an extra key, used to sign the new
> > package and any other package they felt like.
> 
> You don't check the signatur of a debian-keyring update against a
> known good keyring? Maybe the debian-keyring package could add some
> magic to its pre/postrm to check the new keyring on updates to do this
> automatically.
> 
Personally I don't actually have a copy of debian-keyring installed; but
I tend to be against automatic checking of this kind, if a key's going
to be trusted I want to be the one who marks it as trusted.

> > Assuming that level of compromise, there's no recent to suspect that
> > they couldn't have free reign adding anything to the archive they
> > wanted.  Signed .debs gain you nothing here.
> 
> You can detect such a compromised keyring easily if you realy care. So
> for people who care the debian-keyring can't be compromised this
> way. And then signed debs gain security (in the problem we face now
> tih the archive).
> 
I'm still not convinced how they do gain you security?  The assumption
that the MD5 signature and Release GPG signature isn't sufficient is
that the key is stored on a machine that can be compromised.  The same
applies to the keyring itself, so if I can compromise one, surely I can
compromise the other.

Convince me :-)

> The point of the excercise was that the changes files are not
> available to the general public in a crisis situation like now and are
> not easily available at normal times.
> 
I'm not sure how you figure that they aren't easily available, the
list.d.o archive is "easily available".  That being said, I'm not
objecting to putting them anywhere else either, I'm just pointing out
that they are publicly available.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



signature.asc
Description: This is a digitally signed message part

Re: Revival of the signed debs discussion

[Joey Hess]

Wouter Verhelst wrote:
> Requiring us to log in to the autobuilder to sign the .deb remotely is
> not acceptable, for two reasons:
> * it's way too much work for most of us
> * it requires copying the secret key over, which is, uh, a bad idea.
> 
> An alternative would be to copy over the .debs, sign them on the local
> hard disk, and upload them from there. That won't work either; it only
> solves the second problem (as you don't have to copy the secret key
> over), not the first, and it adds a bandwidth-related (if I have to
> download all packages arrakis successfully builds, have to sign them
> locally, and upload them again, I might exceed the download quota my ISP
> has implemented; requesting a higher quota involves paying for it)
> 
> So unless you have a suggestion that would solve this particular issue,
> I'm afraid this idea won't work in practice.

There is nothing in signed debs that prevents you from generating the
fingerprint on the buildd, and mailing it to you for remote signing. It
does require a two step process of first signing the debs, then their
changes file, but this seems ameanable to automation.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Backport of the integer overflow in the brk system call

[Jens Bech Madsen]

On Tue, 2003-12-02 at 17:31, Tom wrote:
> On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote:
> > rather far from changing anything in the kernel memory.  Andreas is
> > definitely right that the hole doesn't look like that it is that dangerous.
> 
> It messed up your life for a couple weeks.
> 
> Jesus, it's not the end of the world, but that's the way Microsoft (used 
> to | still) thinks.
> 
> If it wasn't a big deal we wouldn't be talking about it.  It shut down 
> servers.  It's dangerous enough.
> 

Of course it is a dangerous hole. As you say that has already been
shown.

But the point was that it didn't _look_ dangerous when the bug was
discovered. Had it looked dangerous, a security update would have been
issued.

/Jens

Re: Revival of the signed debs discussion

[Joey Hess]

Andreas Metzler wrote:
> I still don't understand how you change the version number (or the
> package-name) without breaking the signature.

Which signature? The Packages file is being modified, so of course the
hain of trust back to the Release file signature can be used to catch
tampering with it. However, the signature in a deb itself cannot help
against this kind of attack.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bits from the RM

[John Goerzen]

On Tue, Dec 02, 2003 at 12:27:00PM -0500, Noah L. Meyerhans wrote:
> release goal of December 1 didn't inspire any new activity.  This gives
> the appearance that the ARM port maintainers simply don't care if sarge
> gets released at all.  This is very discouraging.

If that is what happens, then I would say "I simply don't care if sarge
is not released for ARM."

> of architectures besides x86 and appreciate its multi-platform support.

Likewise; I run it on three different architectures.

> But, if those who work on Debian on a given platform are no longer
> interested in putting in the effort necessary to maintain that
> architecture, we really should rethink our committment to it.

That is very true.

-- John

Re: Backport of the integer overflow in the brk system call

[Andreas Rottmann]

Tom <[EMAIL PROTECTED]> writes:

> On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote:
>> rather far from changing anything in the kernel memory.  Andreas is
>> definitely right that the hole doesn't look like that it is that dangerous.
>
[snip]
>
> If it wasn't a big deal we wouldn't be talking about it.  It shut down 
> servers.  It's dangerous enough.
>
Note the "looks like".

-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Latein ist das humanoide Ãquivalent zu Fortran.
   -- Alexander Bartolich in at.linux

Re: Revival of the signed debs discussion

[Steve Langasek]

On Tue, Dec 02, 2003 at 06:05:44PM +0100, Andreas Metzler wrote:
> Joey Hess <[EMAIL PROTECTED]> wrote:
> > Goswin von Brederlow wrote:
> >> > dpkg that it is downgrading the package, and a clever attacker might
> >> > avoid even that.

> >> How would you avoid it?

> > Make the replacement package really be a different package entirely, of
> > a higher version than the package it purports to replace.

> > I think aj had some more examples along these lines the last time this
> > came up.

> I still don't understand how you change the version number (or the
> package-name) without breaking the signature.

You change the contents of the compromised Packages file, so that 

Package: bash
Essential: yes
Priority: required
Section: base
Architecture: i386
Version: 2.05b-12

is accompanied by

Filename: pool/main/b/bash/vulnerable-ident-server_1.0-1_i386.deb

which contains a perfectly valid .deb file, signed by a DD, that has
nothing whatsoever to do with bash.

AFAIK, apt does not sanity check the relationship between package names
and filenames (and it's not obvious that this should be part of its
responsibilities), and dpkg only gets a list of .debs to install once
they've been downloaded.

-- 
Steve Langasek
postmodern programmer


pgpKafKvfobmu.pgp
Description: PGP signature

Re: Revival of the signed debs discussion

[Henning Makholm]

Scripsit Wouter Verhelst <[EMAIL PROTECTED]>

> Requiring us to log in to the autobuilder to sign the .deb remotely is
> not acceptable, for two reasons:
> * it's way too much work for most of us
> * it requires copying the secret key over, which is, uh, a bad idea.

Um, perhaps this is really stupid but: Since the signature on an
autobuilt .deb is not really worth more than the security of the
autobuilder, wouldn't it make sense to give the autobuilder its own
keypair that it stores locally with no passphrase and uses to sign
packages unattended?

If an attacker compromises the buildd to the point where he can gain
access to its secret key, he could just as well attack its build
environment, or simply use his access to convincingly forge an email
to you, asking you to sign a malicious package.

-- 
Henning Makholm"We can hope that this serious deficiency will be
  remedied in the final version of BibTeX, 1.0, which is
expected to appear when the LaTeX 3.0 development is completed."

Re: Revival of the signed debs discussion

[Andreas Barth]

* Wouter Verhelst ([EMAIL PROTECTED]) [031202 19:40]:
> As much as I like this idea in principle, storing signatures inside
> .debs has a serious problem: it won't work for us buildd maintainers.

Workability for the buildd maintainers is IMHO _certainly_ one
important thing.


> As I explain in my document on wanna-build (usually at
> http://people.debian.org/~wouter/wanna-build-states, but due to some
> problems with that machine temporarily currently at
> http://www.grep.be/wanna-build-states.html too), buildd maintainers do
> not manually log in to their autobuilder to sign each and every .changes
> on its hard disk; instead, they extract the .changes file from the mails
> of successful messages sent to them (and to [EMAIL PROTECTED],
> which processes them into what people can look up on
> http://buildd.debian.org), sign that, and send it back. In reply, the

What checks do you do to such a package before signing?


> So unless you have a suggestion that would solve this particular issue,
> I'm afraid this idea won't work in practice.

Two suggestions come to my mind. However, I can't judge how useful
they are in reality.

Signing by the buildd:
The buildd could sign the debs by a buildd-key (one key for each
buildd and each year). They could sign e.g. after they get the changes
file back signed by the build admin. The debian archive scripts
accepts packages signed by a buildd-key only if it is a binary package
for this architecture, the key is valid (i.e. in the right year), and
this package has been handed out to this autobuilder for building.

Creating special helper scripts:
It could be possible to extract a small file (more or less like the
current changes file) out of each deb. So you could just sign this
file, and sent it back to the buildd. The buildd would then extract
the signature, and include it into the deb before upload. This would
however need to change the way debsign works: Currently debsign makes
a simple binary stream out of the members of the ar. Instead of this,
debsign should create e.g. a md5sum-file (like the current changes,
but "one level lower") out of the binaries, and then sign this file.
It is possible to write a verify-script that could accept the old and
the new verifying-method.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Bits from the RM

[Brian May]

On Tue, Dec 02, 2003 at 01:46:02PM +, Mark Howard wrote:
> On Tue, Dec 02, 2003 at 06:56:13PM +1100, Brian May wrote:
> > A release critical bug in one package could be caused by a non-release
> > critical bug in another package.
> 
> How?
> If the bug is caused by a problem in another package then it should be
> reassigned (and more importantly fixed). The bug is still RC, even if it
> only affects dependent packages

Wouter already answered the "The bug is still RC part".

However, one point he didn't mention is that if the bug is reassigned in
to the other, people will continue to be affected by the bug against the
package, look up bug reports, not find anything, and resubmit a new bug
report.

If you keep at least one grave bug report open against the broken
package, then it lets its users know that this is a known problem, and
they can be redirected towards the real bug report against the real
package.
-- 
Brian May <[EMAIL PROTECTED]>

Re: Bits from the RM

[Chris Niekel]

On Tue, Dec 02, 2003 at 09:33:39AM -0500, Sam Hartman wrote:
> [...]  It takes me about an
> afternoon to do a PAM or OpenAFS release even if I change one line.
> OK, for a one line change I can probably get that down to two hours or
> so.
> 
> It's a lot easier for me if I batch bugs together and if I did not do
> so, I'd be even more behind than I already am.
> 
> [...] pam is an excellent example of a
> package where I've let things slip enough that I'm having difficulty
> digging myself out of the hole.

With some (creative?) quoting, this reads like a perfect example for the
"request for assistance"-program which Anthony announced. Although I
think pam and openafs aren't the simplest packages. 

My 2 cents as a non-maintainer don't really matter though :)

Greetings,
Chris Niekel

-- 
I've been down so long, if I'd cheer up, I'd still be depressed.
- Lisa Simpson, Moanin' Lisa Blues.


pgpI97zJhuZsg.pgp
Description: PGP signature

Re: [debian enterprise] sub-project planning

[Matt Zimmerman]

On Mon, Dec 01, 2003 at 01:12:52PM -0500, Andres Salomon wrote:

> For packages, we may want to focus on apt-secure
> (http://monk.debian.net/apt-secure/); I'm not sure the status of it, [...]

You could easily find out here:

http://bugs.debian.org/203741

-- 
 - mdz

[custom] The term "flavor" and encouraging work on Debian

[Fabian Fagerholm]

Hi,

Recently, when thinking about the terminology surrounding Debian
Subprojects, I thought about the term "flavor". I always liked that
term, because I find it very descriptive.

I wrote to Zenaan Harkness concerning Debian Enterprise
(http://debian-enterprise.org/), and I suggested that such a subproject
would not be creating just one "Custom Distribution", but a set of
pre-defined choices. Debian Enterprise could, for example, have an
install-time option to set up a file and print server, an authentication
server, or a web server. Those would be _flavors_, in my view. Despite
all that has been written and referenced on this list concerning these
terms, I don't think they are enterily satisfactory. So, I suggest the
following choice of words to clarify "subproject" and "flavor":

Debian is the super-project.
Debian Enterprise is a Debian Subproject that creates
a Custom Debian Distribution,
with the flavors "file and print server", "authentication
server" and "web server".

Actually, I'd like to see the term "Custom Debian Distribution" be set
aside because a "custom" something is created each time someone modifies
an original. Debian Enterprise certainly is an original. By the time a
capable sysadmin has installed it, it will (probably) be "custom".
("Custom Custom Debian Distribution", anyone ?)

The term suggests that the distribution is "not-Debian", which is
unneccessary and confusing. The term "Subproject" suggests that
something is "part-of-Debian", which is to be encouraged.

A Subproject could extend debian-installer to create a set of related
install-time choices. These would be "flavors". (Of course, Debian
itself could also have such flavors.) I really don't see the point of
encouraging more derivative distributions that possibly fork off into
projects of their own, even if it's just a choice of words.

Also, a clean structure will help when explaning things to any of the
target audiences of Debian Enterprise, Debian-NP, Debian-Lex, any of the
other subprojects, or when someone asks about "road maps", "release
schedules", etc. Additionally, "Custom" does not sit well when
introducing Debian Enterprise to your managers. ("Why do we have to use
a custom system? That sounds expensive. Let's go for Windows 2003, that
at least works out of the box with no custom stuff in it.")

Allowing people to mix and match as they like is also a good thing,
which can be achieved if working within Debian and sharing the same
package pool. If you look at Bdale's platform from the last DPL
election, you'll see that he summarized these things quite nicely:
http://lists.debian.org/debian-vote/2003/debian-vote-200303/msg00014.html

So I suggest the following terms:

Debian is the super-project.
XYZ is a Debian Subproject,
which provides the flavors A, B and C.

Opinions?
-- 
Fabian Fagerholm <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: Revival of the signed debs discussion

[Matthias Urlichs]

Hi, Henrique de Moraes Holschuh wrote:

> On Tue, 02 Dec 2003, Wouter Verhelst wrote:
>> So unless you have a suggestion that would solve this particular issue,
>> I'm afraid this idea won't work in practice.
> 
> We could verify if the gpg agent (gpa? I forget the name...) cannot do this
> over a secure channel. It should be able to, and if not, it can probably be
> taught to.

It's not that easy (basically you need to tunnel the actual
encryprion/signing function, not just the passphrase-getting).
See ssh-agent as an example.

The good thing is that people are already thinking about this.

http://lists.gnupg.org/pipermail/gnupg-users/2003-April/017920.html

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
BOFH excuse #387:

Your computer's union contract is set to expire at midnight.

Re: Backport of the integer overflow in the brk system call

[Tom]

On Tue, Dec 02, 2003 at 08:51:50PM +0100, Andreas Rottmann wrote:
> Tom <[EMAIL PROTECTED]> writes:
> 
> > On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote:
> >> rather far from changing anything in the kernel memory.  Andreas is
> >> definitely right that the hole doesn't look like that it is that dangerous.
> >
> [snip]
> >
> > If it wasn't a big deal we wouldn't be talking about it.  It shut down 
> > servers.  It's dangerous enough.
> >
> Note the "looks like".

I read all the words but took a completely different meaning :-)
I'm from the South, we have different speech patterns...

"the hole doesn't look like that it is that dangerous"
means something different than
the hole doesn't look like that it is dangerous"
in my ears ...

"that" is diminuitve in my dialect if you don't put emphasis on it :-)

Re: ITP: konversation -- User friendly Internet Relay Chat client for KDE (fwd)

[Nathaniel W. Turner]

I meant to mention that this is Debian bug #222154.

Re: Some ideas quickly jotted down

[Zenaan Harkness]

On Wed, 2003-12-03 at 08:07, Fabian Fagerholm wrote:
> > (Just looking briefly at the diagram, I'm thinking "The Core" would be
> > the organisation - eg. Enterprise-Debian.org, or UserLinux.com, or
> > whatever is ultimately decided on.)
> 
> Ok. I have probably mixed both technical and organisational things in
> the diagram, which makes it a little confusing. But I generally think
> you _can_ put things from different domains into the same diagram to
> show how they relate to each other. When I started drawing, I began with

I agree. As long as it doesn't get too complex it should be fine.

> the core, which I thought of as "core software" (kernel, etc. as
> specified further down). When moving outwards, I reached more
> organisational things.

Thanks heaps
Zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: Bits from the RM

[Joel Baker]

On Wed, Dec 03, 2003 at 07:17:57AM +1100, Brian May wrote:
> On Tue, Dec 02, 2003 at 01:46:02PM +, Mark Howard wrote:
> > On Tue, Dec 02, 2003 at 06:56:13PM +1100, Brian May wrote:
> > > A release critical bug in one package could be caused by a non-release
> > > critical bug in another package.
> > 
> > How?
> > If the bug is caused by a problem in another package then it should be
> > reassigned (and more importantly fixed). The bug is still RC, even if it
> > only affects dependent packages
> 
> Wouter already answered the "The bug is still RC part".
> 
> However, one point he didn't mention is that if the bug is reassigned in
> to the other, people will continue to be affected by the bug against the
> package, look up bug reports, not find anything, and resubmit a new bug
> report.
> 
> If you keep at least one grave bug report open against the broken
> package, then it lets its users know that this is a known problem, and
> they can be redirected towards the real bug report against the real
> package.

For those playing along at home, I suspect this would look a lot like:

clone XX
severity -1 important
retitle -1 Causes massive failures on package foo
assign -1 bar

(The key trick is the cloning; it keeps the bugs tied in a way that makes
the relationship clear, keeps the discussion history available, and still
allows the bugs to be seen accurately, in the places they should be, and at
severities that are accurate).
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU NetBSD/i386 porter: :' :
 `. `'
   `-


pgpiVYa89Vfaf.pgp
Description: PGP signature

Re: [custom] The term "flavor" and encouraging work on Debian

[Andres Salomon]

On Tue, 02 Dec 2003 22:58:28 +0200, Fabian Fagerholm wrote:

> Hi,
> 
> Recently, when thinking about the terminology surrounding Debian
> Subprojects, I thought about the term "flavor". I always liked that
> term, because I find it very descriptive.
> 
[...]
> So I suggest the following terms:
> 
> Debian is the super-project.
> XYZ is a Debian Subproject,
> which provides the flavors A, B and C.
> 
> Opinions?

I'm always a fan of clearly defined terminology.  I also like the idea of
not limiting a sub-project too much; otherwise we'd probably see a large
number of sub-projects formed, w/ discussion on their respective lists
being splintered (but applicable to more than one).  Flavors sound a lot
like a subset of tasks.  There are task groupings like "gnome", with
another task group like "web-cluster" (that pulls in
apache/ipvs/keepalived/heartbeat/etc).  The difference being that one is
simply a collection of packages, while the other is an
installation or server category.

Re: Revival of the signed debs discussion

[Andreas Barth]

* Steve Langasek ([EMAIL PROTECTED]) [031202 22:10]:
> AFAIK, apt does not sanity check the relationship between package names
> and filenames (and it's not obvious that this should be part of its
> responsibilities), and dpkg only gets a list of .debs to install once
> they've been downloaded.

So this should be handled for a safer environment.

E.g. dpkg could get an explicit "I want downgrade"-switch, along with
an "install without signature validation". With these (and these
switches not used by apt by default), there would be no danger in your
scenario (except wasted bandwith).


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C