Re: [custom] Debian Enterprise - packages

[Zenaan Harkness]

On Thu, 2003-12-04 at 04:42, Andres Salomon wrote:
> On Wed, 03 Dec 2003 14:45:51 +1100, Zenaan Harkness wrote:
> 
> > As per the recommendations from Bruce Perens' User Linux paper
> > http://userlinux.com/white_paper.html, this thread is to discuss the
> > applications within the bounded set of Debian Enterprise/ User Linux.
>
> I think discussing the favorite applications, at this point, is a bit
> premature.  Debian Enterprise (DE) should be concentrating on the
> framework that will make flavors possible.  There is much that remains to be
> done on the technical level (kernels, a distribution that is up-to-date
> enough that companies will _want_ to use it, an installer, etc).  Deciding
> what applications to supply isn't of much use right now (especially given
> the rate of development of some; mozilla-firebird may be a good choice
> now, but what about when epiphany or another alternative becomes the
> better browser?).
> 
> Remember the original goals that DE is attempting to solve. 
> Current Debian-using companies must maintain their own package backports,
> kernels, and so on.  Deciding what browser we will default to, while
> possibly helping in standardization, is a long ways off.  In order for DE
> to become useful, we must cater to companies (not the other way around). 
> Thus, we should build out the infrastructure enough so that DE, by itself,
> is installable and useable.  At that point, we can start worrying about
> what flavors will contain what software.

Good points. I wholly agree.

regards
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: exim4-config and exim4-base installed on systems with non-exim-MTA

[Anthony Towns]

On Wed, Dec 03, 2003 at 08:37:06PM +0100, Marc Haber wrote:
> >the other
> >is to ensure that exim4-base (and config) is "configured" first, which
> >can be done by having them not have a postinst script. That mightn't be
> >good enough.
> Both -base and -config have non-trivial postinst scripts.

The -base postinst script is avoidable: have it supply
/usr/lib/exim4-base/configure-me and then execute that from the -daemon
package. ie, just use the -base package to provide common files that
you don't want to distribute twice (in separate daemon packages), and
put all the execution into the daemon packages.

> The way -config does the configuration is something that is questioned
> by a lot of people. Most conservative eximists hate the configuration
> being split out in several files, and having the separate -config
> package allows people to throw away the entire -config magic.

Okay, that's bad then. What's the -config magic that you can't give up?

Maybe an easy way of answering that is to instead answer this: why can't
you just make the -config package a bunch of files and a script that
doesn't get executed until the daemon package is installed?

> >If that's really out of the question, and the -config or -base package needs
> >a postinst atm, a Pre-Depends is probably the best option.
> Which package should then pre-depend on which other package?

The one that gets installed later, Pre-Deps the one that gets installed
earlier. exim4-daemon Pre-Depends: exim4-config; exim4-config Depends:
exim4-base, probably.

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: [custom] Debian Enterprise - packages

[David Palmer.]

On Thu, 2003-12-04 at 07:04, Russell Coker wrote:
> On Thu, 4 Dec 2003 08:07, "David Palmer." <[EMAIL PROTECTED]> wrote:
> > I note also that Adamantix developers, when a present priority project
> > reaches completion, have expressed a willingness to commit in the
> > process of assisting with Pax incorporation into the Debian kernel.
> 
> Please point out where the Adamantix developers expressed a willingness to 
> help in any way.

Hello Russell,

I searched the Debian-devel archive for the exchanges I read myself, but
do you think that I could find them? No way!
They must be there somewhere, but time is short, so I grabbed this off
the Adamantix site.
I think that it adequately displays Peter Bussers' attitude.
But if you need more, when I have more time I wil conduct a more
thorough search, and even ask Peter for verification if that is what is
required.

Hi!

I got some replies to debian-devel Cc:-ed from people who said that they
wanted to have a kernel-patch package for PaX. After that, I got the following
message:

- Forwarded message from Javier Fern?ndez-Sanguino Pe?a
 -

From: Javier Fern?ndez-Sanguino Pe?a 
To: Peter Busser 
Cc: debian-devel(at)lists.debian.org
Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield)

On Fri, Nov 28, 2003 at 12:20:43PM +0100, Peter Busser wrote:[...]


Just so we move forward, I have packaged today a kernel-patch-package which 
seems to apply as expected with 'make-kpackage' based on the changes you 
have introduced to the kernel_2.4.21_2.4.21-5 package developed by Herbert 
Xu. 

I've sent the ITP (just in case somebody wants to comment or pre-test it) 
and will upload it soo to an upload queue. 

I guess that the rsbac userspace would need to be included in Debian too in 
order for this patch to be useful for Debian users at all, am I correct? 
I'm going to send also the paxtest package you developed in order for 
people to test PaX (and exec-shield's) functionality and decide for 
themselves. I will first write a manpage for it (as mandated per policy) 
though.

Regards

Javi



- End forwarded message -

I'm really happy to receive some positive reactions from Debian related people.
And I am even more happy to see that Javi is willing to help getting this stuff
in Debian.

That does not mean that Adamantix will be obsolete soon, integrating it in
Debian will take time. And there are conflicting interests here (exec-shield,
SELinux and stackguard in the future) that might slow down or stop integration
in Debian (fortunately RSBAC and SELinux can live together in 2.6).

People will find ways around RSBAC, SSP, PaX and whatever is decided to add
next. I suspect that the number of backdoor attempts will increase as soon as
cracking systems becomes harder. Therefore the road to a really high security
system is a long one. We are still at the beginning of that journey.

Groetjes,
Peter Busser[...]

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

[Zenaan Harkness]

On Wed, 2003-12-03 at 22:44, VEROK Istvan wrote:
> On Wed, 3 Dec 2003, Andreas Tille wrote:
> > On Wed, 3 Dec 2003, Fabian Fagerholm wrote:
> >
> > > In my view (as I said), it would be logical to name a further
> > > subdivision of that product "flavor".
> > I like this interpretation of the term flavor and it would be easily
> > applicable for Debian-Med to flavors like:
> >- Medical practice
> >- Medical research
> [snip]
> 
> Just a suggestion on naming:
> 
> Due to the unclear connotations, there is a great deal of confusion over
> the terms "internal project", "subproject", "flavor", "custom Debian
> distribution" and the like.  To clarify my own thinking, I started using
> just "subset" and "mutation" instead.

Basically, any new term we choose will not seem quite right to someone.
It is a matter of deciding on suitable terminology and vigorously
defining it, and then having enough people say "that's good enough, I'll
use it".

If you've been using these terms in your head for a while, they may well
make more sense to you than these other "newer" terms.

Then the more we use it, the more it will make perfect sense. Of course
it should make as much sense to start with...

If you haven't seen it, perhaps the CustomDebian wiki will be useful:

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

On "mutation" - sorry, I don't like this one.

on "subset":

The package sets produced by Debian subprojects, eg. Debian JR, Debian
Med, etc, are not always strictly subsets of Debian - they produce if
nothing else an additional website but also additional packages
(sometimes initially separate from Debian, like Knoppix), and also
customized (eg. desktop) configurations that (so far) have been largely
outside of Debian. So we need a different term (eg. Customization, or
Custom Debian Distribution).

Some subprojects may (initially or eventually, eg. Debian Enterprise)
simply provide recommendations for packages to install - to help
particular end users "navigate" the sheer volume of Debian packages
(perhaps as a "Task" package). You could consider such recommendations
as a Debian subset. It's a good term for that actually, at least in so
far as it refers to a subset of packages. The terms flavor, subset, and
possibly metadistro overlap here.

Other subprojects (eg. Debix/Knoppix) may be proving grounds for new
types of technology (bootable and live cds) that are eventually merged
back into Debian proper (to become "internal" projects, but that
distinction may not be so useful). But before merging, such subproject
package sets are not a subset of Debian.

And some subprojects may not produce or recommend any packages, serving
non-technical functions. (examples anyone?)

cheers
zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://homepages.ihug.com.au/~zenaan/
* PGP Key: http://homepages.ihug.com.au/~zenaan/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Marc Haber]

On Wed, 03 Dec 2003 23:29:22 +0100, Tore Anderson <[EMAIL PROTECTED]>
wrote:
>* Marc Haber
>> The way -config does the configuration is something that is questioned
>> by a lot of people. Most conservative eximists hate the configuration
>> being split out in several files,

>Absolutely, this is a slight convenience for the packagers
>which causes a major inconvenience to the users.  
>Well, in my opinion anyway.

Well, I am only paid to work on the exim4 package if my employer gets
to use the package as well. Since we don't want debconf questions to
pop up during installation and we found the pre-fabricated -config too
inflexible for our needs, -config needs to be split out.

Otherwise, exim4 would not have a co-maintainer.

> > and having the separate -config package allows people to throw away
> > the entire -config magic.
>
>  How?  (Short of creating a empty replacement -config package.)

The source package holds infrastructure for three possibilities:

- A script is included that splits out -config source from the source
  package, allowing the debconf stuff to be modified independently
- A script is included that creates a debconf-less -config source
  package that uses split config.
- A script is included that creates a -config source package with 
  monolithic config.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: Status of brk vulnerability in kernel-source-2.4.20-11, 2.4.21-5, 2.4.22-3?

[Marc Wilson]

On Wed, Dec 03, 2003 at 05:38:11PM -0500, Nathanael Nerode wrote:
> The security advisory does not mention these (the current 2.4.x kernels
> available in sarge), and the upstream fix is apparently not until 2.4.23.

No offense... but (a) why would the DSA mention Sarge, and (b) isn't it
obvious that the kernels in Sarge are affected, as (1) there has been no
opportunity to move a patched kernel to Sarge, and (2) Sarge doesn't have
security updates in the first place?

It seems to me that all Sarge kernels have the vulnerability, and that you
should proceed on that assumption.

-- 
 Marc Wilson | If there is no God, who pops up the next Kleenex?
 [EMAIL PROTECTED] | -- Art Hoppe

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Miles Bader]

Sebastien Bacher <[EMAIL PROTECTED]> writes:
> I'm not sure that's a good idea. I'm using Gnome and I'd like to keep a
> simple applications' menu, not having hundred entries like in my
> debian's menu. Having too many entries in a menu is an usability problem
> imho (it's very annoying to search an item in the middle of long
> menus). If you are using non KDE/Gnome apps you should perhaps add some
> launchers in the desktop for them ?

I disagree entirely.

I use gnome and I find the `builtin' gnome application menus pretty much
useless -- they point to a few token applications that I don't use, and
don't have any of the interesting applications.

The debian menus (I mean those under the top-level label `Debian' in the
Gnome foot menu), OTOH, are _much_ better:  they actually have the
applications I installed!  They are are also quite well organized, I
don't find them cluttered at all.

I think dropping the current `auto add' behavior of menus would be a
_serious_ mistake.

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Assurance measures: AGD (that fabulous manual we like to have but hate to write)

[(mag)]

Hi!


AGD_ADM.1 Administrator guidance (all EALs)

AGD_ADM.1.1D   The developer shall provide administrator guidance
addressed to system administrative personnel.
(This is man 8, and the various administrators' guides
and HOWTOs. We do have it in most cases. Thanks to the
LDP project and the numerous people who have written it.)
AGD_ADM.1.1C The administrator guidance shall describe the
administrative functions and interfaces available to the
administrator of the TOE.
(It works in most cases. The GNU coding standards mandate
that even the --help option should do its essentials.)
AGD_ADM.1.2C The administrator guidance shall describe how to administer
the TOE in a secure manner.
(Well, there docs where you can find warnings about security,
and unfortunately there are the ones which describe insecure
practices.)
AGD_ADM.1.3C The administrator guidance shall contain warnings about
functions and privileges that should be controlled in a secure
processing environment.
(See above)
AGD_ADM.1.4C The administrator guidance shall describe all assumptions
regarding user behaviour that are relevant to secure operation
of the TOE.
(These assumptions are not made explicit in a lot of cases,
and because that they do not get into the admin guide.)
AGD_ADM.1.5C The administrator guidance shall describe all security
parameters under the control of the administrator,
indicating secure values as appropriate.
(Where we have admin guide, the parameters are described
in most cases, but there are indication only in a few
spots.)
AGD_ADM.1.6C The administrator guidance shall describe each type of
security-relevant event relative to the administrative
functions that need to be performed, including changing the
security characteristics of entities under the control of the
TSF.
(It is also a grey spot in a lot of cases.)
AGD_ADM.1.7C The administrator guidance shall be consistent with all
other documentation supplied for evaluation.
(Well, being up-to-date is a great challenge with free
software. From that perspectiveit works with a surprisingly
high percentage of packages.)
AGD_ADM.1.8C The administrator guidance shall describe all security
requirements for the IT environment that are relevant to the
administrator.
(It is nearly the same case as the assumptions about user
behaviour.)

AGD_USR.1 User guidance (all EALs)

AGD_USR.1.1D   The developer shall provide user guidance.
(manpages, user guides, howtos. See AGD_ADM.1.1D)
AGD_USR.1.1C   The user guidance shall describe the functions and
interfaces available to the non-administrative users of the TOE.
(It exists in most cases. See AGD_ADM.1.1C)
AGD_USR.1.2C   The user guidance shall describe the use of
user-accessible security functions provided by the TOE.
(It is okay more often than not.)
AGD_USR.1.3C   The user guidance shall contain warnings about
user-accessible functions and privileges that should be
controlled in a secure processing environment.
(Well, sometimes they do, sometimes don't.)
AGD_USR.1.4C The user guidance shall clearly present all user
responsibilities necessary for secure operation of the TOE,
including those related to assumptions regarding user behaviour
found in the statement of TOE security environment.
(I guess that there are only a few cases where these
statements exists, and only a bit more where the
responsibilities are described.)
AGD_USR.1.5C The user guidance shall be consistent with all other
documentation supplied for evaluation.
(See AGD_ADM.1.7C)
AGD_USR.1.6C The user guidance shall describe all security requirements
for the IT environment that are relevant to the user.
(See AGD_ADM.1.8C)

Re: [custom] Debian Enterprise - packages

[Benj. Mako Hill]

On Tue, Dec 02, 2003 at 10:49:20PM -0600, John Goerzen wrote:
> If you think you can get every large enterprise worldwide to standardize
> on a single scripting language -- much less get even ONE to do that --
> then you will surely be nominated for several nobel prizes.

Rather, the most you'll get is dismissive comments on mailing lists
for *thinking* it. Fame and glory happen when you actual *do* it.

In any case, picking a language to standarize upon within a subproject
seems sensible although forcing this on users is hardly the Debian Way
or likely to be a very productive experience. It's unclear from the
original message which one is being advocated here but I'll assume
it's the former. :)

Regards,
Mako

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



pgpZ35hkRz05v.pgp
Description: PGP signature

Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[Fabian Fagerholm]

On Wed, 2003-12-03 at 16:02, Benj. Mako Hill wrote:
> If you apt-get install the subproject-howto you will get something
> talking *only* about creating a custom Debian-distribution -- not
> about creating a subproject for any other sort of work. The folks at
> the BOF saw a real lack of interaction between the people making
> custom distributions and we attributed this, in part, to the fact that
> we didn't have a single concept around which identify and say, "yeah,
> that person is doing the same thing as me, we should work together."
> The flavors people were not working with the metadistros people and
> the subproject people where on their own.

Can you say who the flavors people, the metadistros people and the
subproject people were? I'd like to make contact with all of these to
get more details about their respective projects and their view on this.

> I think we left with the idea that "flavors" or "metadistros" and the
> like may still describe *technologies* or methods which one could use
> to achieve a Custom Distro.
> 
> I think this is in line with what AJ, yourself, and others have said --
> which is nice. :)

Very good indeed. :)

> I think it absolutely should. I also think the HOWTO should be renamed
> or expanded in scope to bring it into alignment with the consensus that
> seems to be coalescing around these issues.

I have contacted Ben Armstrong and proposed that the scope of the HOWTO
be expanded to cover all subprojects -- as the title suggests it should
-- and explain the relationship of the terms "subproject", "Custom
Debian Distribution" and "flavor" as defined in this thread.

I want to collect knowledge and pieces of text from all who have some
experience with subprojects, and work that material into the HOWTO. I
will contact some subproject people shortly to get their input. Any
pointers will be appreciated.

Cheers,
-- 
Fabian Fagerholm <[EMAIL PROTECTED]>


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

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

[Benj. Mako Hill]

On Wed, Dec 03, 2003 at 12:44:17PM +0100, VEROK Istvan wrote:
> Due to the unclear connotations, there is a great deal of confusion over
> the terms "internal project", "subproject", "flavor", "custom Debian
> distribution" and the like.  To clarify my own thinking, I started using
> just "subset" and "mutation" instead.

I don't mean any offense to you or your terms but I think that the
major source of the confusion is not the the imprecision of the terms
because (as other have pointed out) all terms are imprecise. The major
problem is the *number* of these terms. Adding one or two more, even
with their benefits, would IMHO be counteproductive at this point.

Regards,
Mako


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



pgpHM3TfGYHql.pgp
Description: PGP signature

Re: debsums for maintainer scripts

[Javier Fernández-Sanguino Peña]

On Thu, Dec 04, 2003 at 03:07:52AM +0100, Goswin von Brederlow wrote:
> Anthony DeRobertis <[EMAIL PROTECTED]> writes:
> 
> > On Wed, 2003-12-03 at 05:23, Manoj Srivastava wrote:
> > 
> > >   Because it buys little security wise? 
> > 
> > I can take a rescue disk, a CD with relevant packages on it, boot the
> > suspect server from the rescue disk, and quickly check md5sums. At
> > least, if all packages had md5sums I could.
> 
> You can just as well just check all the debs. gunzip doesn't take
> longer, the slowest thing usually is the cdrom.

¿You mean from your CDs? You won't usually have up-to-date CDroms with the 
security updates (at least I don't). So, if you lack a network connection, 
you would need to download the archive, make a CD... 

I was about to say that you needed your own tools, but then I found
debsums' --deb-path option. Still, it would be best if you could download a
list of valid MD5sums from your favorite Debian mirror (an option not
currently available) instead of all the .deb and then manually extract the 
md5sums from them. That list could be provided on a per-Release basis 
together with separate lists for security updates and proposed-updates [1] 
and could be checked automatically by tools like debsums, running of a CD.

Regards

Javi

[1] Similar to our Contents-* files but providing the md5sum within it too.
Hmm... I think I'm going to submit a wishlist bug to ftp.debian.org


signature.asc
Description: Digital signature

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Tore Anderson]

* Marc Haber

 > Well, I am only paid to work on the exim4 package if my employer gets
 > to use the package as well. Since we don't want debconf questions to
 > pop up during installation and we found the pre-fabricated -config too
 > inflexible for our needs, -config needs to be split out.

  So I take it you roll your own exim4-config-marchaber or something
 which provides exim4-config?

  If so, that does in no way explain the reasoning behind splitting
 up the default configuration file in a million tiny files, nor why
 simply creating a exim4-base-marchaber with the customized scheme
 isn't adequate for you.

  I'm glad to hear you're paid to work on Debian, as that certainly
 makes it even more fun.  :)

* Marc Haber 

 > and having the separate -config package allows people to throw away
 > the entire -config magic.

* Tore Anderson

 >  How?  (Short of creating a empty replacement -config package.)

* Marc Haber

 > The source package holds infrastructure for three possibilities:
 >
 > - A script is included that splits out -config source from the source
 >   package, allowing the debconf stuff to be modified independently
 > - A script is included that creates a debconf-less -config source
 >   package that uses split config.
 > - A script is included that creates a -config source package with 
 >   monolithic config.

  In other words, «people» must be familiar with the process of building
 Debian packages, and must be willing to spend time learning this Debian-
 specific infrastructure to be able to manage their Exim installation in
 a generic and non-Debian-specific manner.  I don't really see that as
 being advantageous to a more than a select few users.

  Furthermore, I still don't see the reasoning behind and/or advantages
 incurred by splitting off the exim4-config package and splitting the
 config file into all those tiny conf.d-snippets.

  I would suggest something like this:

- A exim4-base package containing the default debconf scripts,
  which installs a (monolithic) configuration file.
- The source package could then, to cater for power users such as
  yourself, contain scripts to
  1) split out the -base source from the source package, allowing
 the debconf stuff to be modified independently, and
  2) create a debconf-less -base source package that uses
 monolithic config, and possibly
  3) create a debconf-less -base source package that uses
 split config, and possibly
  4) create a -base source package that uses split config.
- exim4-daemon-whatever declares a dependency on
  exim4-base-custom | exim4-base, or exim4-base-custom declares a
  provides for exim4-base.
- exim4-daemon-whatever declares a provides for exim4-daemon, and
  exim4-base[-custom] declares a depends on this virtual package.

  What point have I missed that makes this inferior to the way the Exim
 packages are currently structured?

  As an added bonus, implementing this will also make the problem you
 initially inquired about go away.

-- 
Tore Anderson

送你一张国际信用卡！！网赚从此不用愁！！！！

[card]

 ËÍÄãÒ»ÕŹú¼ÊÐÅÓÿ¨£¡£¡Íø׬´Ó´Ë²»Óó£¡£¡£¡

Freecashcards¹ú¼ÊÐÅÓÿ¨£¬ÒÔÇ°ÉêÇëÐèÒªÊÖÐø·Ñ39.5$£¬ÎªÁËÔÚÈ«ÊÀ½çѸËÙÆÕ¼°£¬ÏÖÔÚÊÖÐø·ÑÈ«·Ñ£¬¶øÇÒ×¢²á¾ÍËÍÄã5$
 £¡Äã¿ÉÒÔ
½«ACH, wire, cashiers checks, money orders, e-gold, NetPayµÈÕÊ»§µÄǮתÈë 
FreecashcardsÊÇÒ»¼ÒÃÀ¹úµÄÍøÉÏÒøÐУ¬¿ÉÈ«Çò°ìÀíÉêÇë¹ú¼ÊÐÅÓÿ¨ÒµÎñ£¬ÐÂ×¢²áËÍ$5£¬Ã¿½éÉÜÒ»¸öÏÂÏ߿ɵÃ$1£¬´ÓÄãµÄÏÂÏßµÄÏÂÏß»¹
¿ÉµÃ$1¡£¿É²»Òª´í¹ý»ú»á°¡£¡£¡ÓÐÁËÕâÕÅ¿¨´Ó´Ë¸ãÍø׬²»Óó£¡£¡£¡ 
¹ú¼ÊÐÅÓÿ¨ÇëÉêÇë
[ÉêÇë²½Öè]
1¡¢µã»÷Õâ¸öÁ´½Óhttp://www.freecashcards.com/?ref=12620È»ºóµãÒ³ÃæÓÒÉÏ·½µÄÓÐ"Get 
$5 for signing up!"×ÖÑùµÄÍÖÔ²ÐÎͼƬ¡£ 

2¡¢½øÈ뿪ʼÌîд±í¸ñ£º
Your name:ÄãµÄÃû×Ö£¬ÐÕºÍÃû·Ö¿ªÌÖмäµÄ¿Õ¸ñ²»ÒªÌ
E-mail address:ÓÊÏäµØÖ·£¬
Password:ÃÜÂ룬
Confirm Password:ÔÙÊäÒ»´ÎÃÜÂ룬
Referrer ID:½éÉÜÈËIDºÅ£¨ÇëÌî12620£©
[ ] I agree with terms and conditions. Ç°ÃæµÄ¿òÖдò¹´£¬±íʾͬÒâÌõ¿î¡£
µã"Register"£¡½øÈëÈ·ÈÏ»­ÃæÔÙµã"Register"È»ºóÈ¥ÄãµÄµç×ÓÓÊÏäÊÕ»¶Ó­ÐÅ£¬¸øÄãÒ»¸öÕʺţ¬¾ÍOKÁË
 
ÄãÉêÇëÍêÁËÕʺţ¬¿¨¿ÉÒÔÒÔºóÔÙÉêÇë¡£ÒÔºóÄ㻹¿ÉÒÔÔÚÄãµÄÕʺÅÄÚÉêÇëglobalonecard¿¨£¬ÐèÒª$27£¬ÐèҪ˵Ã÷µÄÊÇ:µ±ÄãµÄÕʺÅÉÏÓÐ27$
»òÕßÄãÄÜͨ¹ýE-GOLD,NetPay»òÕßÆäËüµÄתÕË·½Ê½ÏòÄãµÄÕʺÅתÕË27$£¬ÄÇôÄã¾Í¿ÉÒÔÔڵǼÒÔºóµÄ"Order
 new card"Ñ¡ÏîÀ´ÉêÇëÄãµÄ¹ú
¼ÊÐÅÓÿ¨¡£ÆäÖÐ7$ÊÇÓʼÄÄãµÄ¿¨µÄ·ÑÓã¬20$ΪÒøÐиøÄã°ì¿¨µÄ·ÑÓã¡ÊµÖÊÉÏÄãÖ»ÒªÀ­22¸öÈ˼ÓÈë¾Í¿ÉÒÔÉêÇëglobalonecard¿¨ÁË£¡Ê±¼ä
ÊDz»µÈÈËÁË£¡¿ì£¡ 
http://www.freecashcards.com/?ref=12620
ÓÐÁËÕâÕÅ¿¨£¬ÄãËæʱ¿ÉÒÔ°ÑÄãÕʺÅÉϵÄǮת½ø¿¨À×îÉÙ$25£©¡£×îÖØÒªÊÇÄ㻹¿ÉÒÔ°ÑE-GOLDÉϵÄǮҲÄÜתµ½¿¨ÉÏ¡£ÕâÕÅ¿¨ÔÚÈ«ÊÀ½ç600
£¬000̨ÓÐ"Maestro/Cirrus"±êÖ¾µÄATMÉ϶¼ÄÜÈ¡Ç®£¬ÔÚÖйú´ó¶àµØ·½¶¼ÓÐÕâÑùµÄATM»ú¡£Äã¿ÉÒÔÏÖÔÚ²éÕÒ£º
 
http://www.mastercard.com/cardholderservices/atm/ÏȲéÕÒ¹ú¼Ò£ºÖйú£¬È»ºóÔÙÕÒ³ÇÊС£¾Í¿ÉÒÔÕÒµ½ATM»úµÄ¾ßÌåλÖá£
 

Ò»ÕÅVISAºÍMasterÐÅÓÿ¨¶ÔÍø׬µÄÒâÒåÓжà´ó£¬´ó¼Ò¶¼ÐÄÕÕ²»Ðû¡£ÓÐÁ˹ú¼ÊÐÅÓÿ¨ÎÒÃÇÔÙÒ²²»Óû¨Éϼ¸Ì졢ʮ¼¸Ìì¡¢Éõµ½¼¸Ê®ÌìµÄʱ¼ä
µÈ»ã¿îµ¥£¬£¨¶øÇÒ»¹²»Äܱ£Ö¤ÄÜÊÕµ½£©¡£ÏÖÔÚÎÒÃÇÔÚ¹úÄڵģÁ£Ô£Í»úÒ²ÄÜÁ쵽ǮÁË¡£ 
http://www.freecashcards.com/?ref=12620
 

Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[Andreas Tille]

On Thu, 4 Dec 2003, Fabian Fagerholm wrote:

> Can you say who the flavors people, the metadistros people and the
> subproject people were? I'd like to make contact with all of these to
> get more details about their respective projects and their view on this.
Here on debian-devel. (Can you hear me? ;-) )

> I want to collect knowledge and pieces of text from all who have some
> experience with subprojects, and work that material into the HOWTO. I
> will contact some subproject people shortly to get their input. Any
> pointers will be appreciated.
Beacuse of unavailablity of people.d.o I copied the most important
stuff to

  http://www.physik.uni-halle.de/~e2od5/cdd/200311_lux_cust/

I plan to write a written paper about the things I've said in this
talk which for sure might go into the subproject howto.

Kind regards

  Andreas.

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

[Zenaan Harkness]

On Thu, 2003-12-04 at 20:23, Fabian Fagerholm wrote:
> On Wed, 2003-12-03 at 13:44, VEROK Istvan wrote:
> > Subsets can also have subsets, or a subset may even come from the
> > confluence of other subsets, so there is no need to name one level a
> > "custom Debian distro" and another level a "flavor".
> 
> I'll elaborate more in a later post, but I just want to give a quick
> comment here.
> 
> In the light of the previous discussions, we have to distinguish between
> an *organisational* term and a *technical* term. It's not a very sharp
> distinction in some cases. For example "package pools" is organisational
> in one context but it is also clearly a very technical term since it has
> a concrete implementation in the archive and the package tools.
> 
> Anyway, "flavor" is a technical term. "Custom Debian Distribution" is an
> organisational term.

Organisational, as in "package pool" is also organisational ?? - this is
what your clear exposition of the three layers has lead us to basically
agree on up to this point, and I could almost cut and paste your email
into the wiki it was so clear (at least Debian parent(super) project ->
CDD -> Flavor).

I hope I haven't misunderstood you,
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: [RFC] adding system users: which is the best way??

[Andreas Metzler]

Peter Palfrader <[EMAIL PROTECTED]> wrote:
> On Wed, 03 Dec 2003, Andreas Metzler wrote:
>> Steve Greenland <[EMAIL PROTECTED]> wrote:
>> [...]
>>> I think the idea of a namespace for usernames used by packages is a good
>>> idea, but rather than "debian-", we should take this to the LSB folk, so
>>> that we can get it done once.

>> The problem with this is time. I need to add a system-user (for exim4)
>> _now_. Shall I go for namespace, and if yes which one? _debian-exim,
>> debian-dexim, DEB-exim?
[...]
> Fabbione and I will use debian-sks.  We will summarize and file a bug
> against policy next week or so (being quite busy right now).  Feel free
> to beat us with submitting a problem description and summary :)

"debian-" is rather long. ls only shows the first eight characters. How about
something ugly but shorter?
* "Metacharacter" followed by "deb-", e.g. _deb-sks or "#deb-sks"
* use capital letters. DEBsks
  cu andreas

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

[Fabian Fagerholm]

On Wed, 2003-12-03 at 13:44, VEROK Istvan wrote:
> Subsets can also have subsets, or a subset may even come from the
> confluence of other subsets, so there is no need to name one level a
> "custom Debian distro" and another level a "flavor".

I'll elaborate more in a later post, but I just want to give a quick
comment here.

In the light of the previous discussions, we have to distinguish between
an *organisational* term and a *technical* term. It's not a very sharp
distinction in some cases. For example "package pools" is organisational
in one context but it is also clearly a very technical term since it has
a concrete implementation in the archive and the package tools.

Anyway, "flavor" is a technical term. "Custom Debian Distribution" is an
organisational term. So they describe different things. Exactly what, I
must get back to you on that.

Sorry, I have to run now, but I'll try to get back to this asap. Don't
worry, the terms will be good and then we can all get back to
implementing things when we have the words to communicate with.

Cheers,
-- 
Fabian Fagerholm <[EMAIL PROTECTED]>


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

Re: The term "Custom Debian Distribution"

[Zenaan Harkness]

On Thu, 2003-12-04 at 19:25, Fabian Fagerholm wrote:
> I want to collect knowledge and pieces of text from all who have some
> experience with subprojects, and work that material into the HOWTO. I
> will contact some subproject people shortly to get their input. Any
> pointers will be appreciated.

I like the idea of the HOWTO being the canonical location. Please be
sure to see the wiki:
http://wiki.debian.net/?CustomDebian

and ideally incorporate all of that into the HOWTO, or as much as makes
sense - and once that is done, the wiki should then be updated to refer
to the howto's location on debian.org, with a note on the wiki that new
additions/ comments can be added to the wiki, to be further incorporated
into the HOWTO at a later date. Better to reduce duplication in this way
I think...

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: OT: Smartcards and Physical Security

[Dave Holland]

On Wed, Dec 03, 2003 at 09:32:37AM -0600, Manoj Srivastava wrote:
>   Laptops with biometric print readers are supposed to be around
>  the horizon as well.

If you're talking about laptops with fingerprint readers, they're
consumer items right now. The sales manager at my ex-employer had one
for the "cool" factor.

But fingerprint readers aren't terribly reliable, or (apparently)
difficult to fool.

Dave

Re: Bits from the RM

[Rene Mayrhofer]

Anthony Towns wrote:
* #203339 - freeswan - Rene Mayrhofer
  FTBFS, patch in the bug log since July, no further activity
I feel that I need to respond to that, after being mentioned here :)
I fully admit that I have simply overlooked this one, because it is very 
easy to fix (and indeed has been fixed in my development tree, but 
didn't make it into the last upload). The reasons for not paying close 
attention to "the other" bugs for quite some time were mostly:
- trying to get the whole kernel patch mess to work with the Debian 
kernels and still trying to retain compatibility with vanilla kernels
- constantly fighting with the hack that's called NAT Traversal
- a lot of "real life" issues since August, like moving into a new flat
This is no real excuse and I should pay closer attention to _all_ RC bug 
reports, thanks for reminding me ;)

PS: 2.01-4, which fixes at least some of the bugs, is stuck in the 
incoming queue since about 2003-11-20, nobody to blame for that of 
course. 2.04-1, which fixes all RC bugs and a few of the other ones, is 
currently in the works, but is having problems with the 
kernel-patch-freeswan package (because the changes from 2.01 to 2.04 
upstream are larger than one would expect). If anybody wants to give it 
a try, please drop me a mail and I will send what I currently have. I 
could need some help in testing it with various kernel configurations

PPS: I am not subscribed to debian-devel, so please CC me in replies.
best regards,
Rene

Re: [RFC] adding system users: which is the best way??

[Andreas Metzler]

Zenaan Harkness <[EMAIL PROTECTED]> wrote:
> On Thu, 2003-12-04 at 01:51, Andreas Metzler wrote:
[...]
>> The problem with this is time. I need to add a system-user (for exim4)
>> _now_. Shall I go for namespace, and if yes which one? _debian-exim,
>> debian-dexim, DEB-exim?

> This might be pointing out the obvious, but anyway:

> If nothing else, perhaps email a freedesktop list to get a tentative/
> quick discussion of the topic - put some suggestions up there if you
> want to pre-empt particular convention, and tell them what you chose
> after a few days. Pre-existing usage (if you're the first), especially
> as the result of discussion with the relevant people, will add something
> to the decision process, hopefully toward not having to make changes in
> the future.

Can you suggest the correct list? (Don't bother if you don't know it
by heart and need to look it up, too.)
   cu andreas

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

[VEROK Istvan]

> I don't mean any offense to you or your terms but I think that the
> major source of the confusion is not the the imprecision of the terms
> because (as other have pointed out) all terms are imprecise. The major
> problem is the *number* of these terms. Adding one or two more, even
> with their benefits, would IMHO be counteproductive at this point.

Agreed.

The reason I brought them up at all was that I think the other terms
don't always distinguish between (to borrow Fabian Fagerholm's terms) 
organizational and technical categories (a "subproject" may equally mean a
bunch of people and a bunch of bits).

This is sometimes problematic.  A particularly acute example: I'm in the
middle of packaging a game called CSP.  CSP stands for Combat Simulator
Project -- is that a bunch of people or a bunch of bits?  Project or
product?  To exacerbate the problem, the acronym CSP has other well-known
meanings, too (Hoare's Communicating Sequential Processes come to mind
immediately), so to disambiguate, I have taken to calling this game
CSPSim.  Icing on the cake: sometimes even the construct "CSPSim project"
appears in communication, upsetting my linguistic sensibilities on each
such occasion.

The moral is, I guess, not to seek new terms but to use the already
existing ones carefully.

Cheers,
Istvan


PS: I don't really have anything more to add to this thread, it already
starts to feel a bit like "The Life of Brian", where the People's Front of
Judea prepare to attain world supremacy within the next five years: "We
could sit around here all day talking, passing resolutions, making clever
speeches.  It's not going to shift one Roman soldier!"

Just some free association on my part, no offense to anyone meant,
of course.

Re: debsums for maintainer scripts

[Eduard Bloch]

#include 
* Manoj Srivastava [Wed, Dec 03 2003, 04:19:59AM]:

> > - current md5sums file in control.tar.gz should contain checksums of
> >really all files
> 
>   Hard to do for conffiles. Now, if the md5sums were generated

Then only add the m5sums of the control.tar.gz contents and add it to
the list created my dh_md5sums.

>  at install time, you could checksum my locally modified conffile
>  (even if I did not accept the maintainers changes). The md5sums
>  stored for conffiles currently are rarely any good, since the files
>  are often modified by the admin.

This needs more work. I think Debian should archive the original
versions of conffiles on the target filesystem anyways - the absence of
them is a handicap for any long-term solution.

> > - a signature of the md5sums file should be stored either in
> >control.tar.gz or in the ar file itself
> 
>   So you have to download the package itself to check the
>  contents of the md5sum fule? Why not generate the md5sums at this
>  point anyway?

Or they can be stored in the Extended-Contents-* files (or such) in the
archive for random access, see the original mail and others.

> > - new dpkg version should pickup the signature files and store them
> >either in /var/lib/dpkg/info or in some alternative directory
> 
>   Or you could sign the newly generated md5sum files at install
>  time, complete with the checksums of the locally modified conffiles,
>  and not have to depend on knowing the key of the persons producing
>  the Packages file.

But then you depend on a key that has stored on the local system - and I
am not sure whom the user should trust more when the system has been
compromised. And, as said, it requires additional work during the
installation.

MfG,
Edurd.
-- 
Die besten Reformer, die die Welt je gesehen hat, sind jene, die bei
sich selbst anfangen.
-- George Bernard Shaw

Re: debsums for maintainer scripts

[Bernhard R. Link]

* Goswin von Brederlow <[EMAIL PROTECTED]> [031204 02:46]:
> "Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> > I don't think so. md5-calculation it not the fastest thing (especially
> > on non-i386 it often feels like downloading and installing together
> > needs less time than the md5sum-verification.
> > So this should be switched off, but then it will be missing when one
> > needs them.
> 
> The md5sum file should be generated at build time, signed and only the
> signature kept. The signature is small enough not to cause bloat, it
> can be included in the Package file or a Signatures.gz file containing
> all signatures could be maintained in the archive.

That still adds the burden of calculating them all after installing.
I also think it is hardly possible to regenerate the .md5sums file
in a way the signature will be kept. It would need to never change
which files are included and how they are sorted. It could also
cause problems with more sophisticated Replaces and may bite with
other things I cannot even think about.

> > Its also a warm feeling to run debsums to see the broken memory chip
> > one just replaced with a working one has not caused any bit-changes
> > in the installed files. If the checksums were created at the same
> > system, one has to get them from somewhere else, so there is little
> > sense in having them generated at all.
> 
> The signature of the locally generated ones wouldn't match the one in
> the Packages or Signatures file. If the Packages/Signatures file has
> been tampered with itself (passed through bad memory) one gets a few
> false negatives but never (1:874584575... whatever the hash size is
> there) a false positive.

Only if there is a reliable way to regenerate them at instalation time.
And if one decided to save the time to calculate them or save the space
by freeing the generated .md5sums file, bringing the system back in a
state where such integrity can be checked is almost equivalent to
a reinstall, while extracting the classical .md5sums file from an 
package pool (local mirror, set of CDs ...) and putting them back in
place is very simple and needs far less processing power.

Hochachtungsvoll,
  Bernhard R. Link

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

Re: [custom] Debian Enterprise - packages

[Russell Coker]

On Thu, 4 Dec 2003 16:44, "David Palmer." <[EMAIL PROTECTED]> wrote:
> On Thu, 2003-12-04 at 07:04, Russell Coker wrote:
> > Please point out where the Adamantix developers expressed a willingness
> > to help in any way.

That message was intentionally to you not the list.  Now we will have another 
flame-war.

> I searched the Debian-devel archive for the exchanges I read myself, but
> do you think that I could find them? No way!
> They must be there somewhere, but time is short, so I grabbed this off
> the Adamantix site.
> I think that it adequately displays Peter Bussers' attitude.

The web site does not seem to match Peter's actions.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Revival of the signed debs discussion

[Andreas Barth]

* Wouter Verhelst ([EMAIL PROTECTED]) [031203 23:10]:
> Op wo 03-12-2003, om 10:09 schreef Andreas Barth:
> > > > 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.
> > > 
> > > Valid for the autobuilder the package has been handed to and that send
> > > it in and if the changes file is correct.
> > > 
> > > But what if the buildd failed and someone manually build the deb,
> > > signes it and uploads? The debian archive scripts would need a way to
> > > distinguish between autobuild packages and manually build binary-only
> > > uploads.
> 
> I don't see why that would be the case. Could you elaborate?
>
> > The archive script would of course continue to accept any deb by any
> > DD under the same conditions as today. The question to the
> > buildd-admins is: How often does this happen?
> 
> Hardly ever, if at all. Most "manual" bin-NMU's are done by people that
> are not buildd admins.

I don't understand what you mean. Perhaps it would be best if I try to
rephrase my ideas:

The archive scripts accept a package currently if the following
conditions are met:
* There is an signed changes file for the debs by a DD

These would be harded to the following:
* There is an signed changes file for the debs by a DD
* The debs are signed
  - by an DD
  or
  - by an buildd, if this buildd was the one to build this package.

So, the archive scripts don't distinguish between autobuild packages
and manually build binary-only packages, but they look at the debs,
and verify the signature. If the signature is by a DD, everything is
ok. If the signature is by a buildd, they verify that the buildd had
had an job to build this deb.


Ok?



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: exim4-config and exim4-base installed on systems with non-exim-MTA

[Andreas Barth]

* Tore Anderson ([EMAIL PROTECTED]) [031203 23:55]:
> * Marc Haber

>  > The way -config does the configuration is something that is questioned
>  > by a lot of people. Most conservative eximists hate the configuration
>  > being split out in several files,
 
>   Absolutely, this is a slight convenience for the packagers which causes
>  a major inconvenience to the users.  Well, in my opinion anyway.

In my opinion the way exim4 handles the configuration adds a major
benefit for the persons using exim4.


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: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Cameron Patrick]

On Thu, Dec 04, 2003 at 12:19:28PM +, Andrew Suffield wrote:
| On Thu, Dec 04, 2003 at 12:34:22AM +0100, Raphael Goulais wrote:
| > On Wednesday 03 December 2003 21:31, Zenaan Harkness wrote:
| > > I agree. I would like to see .desktop standard adopted. There have been
| > > a few threads I have seen so far, and there seems to be some level of
| > > resistance to the idea.
| > 
| > The silly question is : What does our actual menu system provide that 
| > shouldn't be achieved by using .desktop file ?
| > 
| > As those are going to be a standard, we should deal with them.
| 
| You could swap "our menu system" and ".desktop files" here and your
| argument would still be about as valid.

I don't think that this is the case.  As I understand it, .desktop files
have the advantage that they are already shipped by a number of upstream
packages, support i18n better than Debian menus, are supported natively
by KDE and Gnome, include facilities for providing stuff like generic names
and are supported by the freedesktop.org folk.

The main advantage of the Debian menu system, on the other hand, seems
to be that it is already in place in most .debs which provide menu
entries and menu methods.

(The above was gleaned from reading past threads, BTW, not from intimate
knowledge of the two systems.  The worst situation, IMHO, is to see the
two mesh poorly, such as the KDE menus which show "Debian" submenus
under a lot of categories, presenting applications with .desktop entries
separately from those which only have Debian menu entries.)

Cameron.

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Andrew Suffield]

On Thu, Dec 04, 2003 at 12:34:22AM +0100, Raphael Goulais wrote:
> On Wednesday 03 December 2003 21:31, Zenaan Harkness wrote:
> > I agree. I would like to see .desktop standard adopted. There have been
> > a few threads I have seen so far, and there seems to be some level of
> > resistance to the idea.
> 
> The silly question is : What does our actual menu system provide that 
> shouldn't be achieved by using .desktop file ?
> 
> As those are going to be a standard, we should deal with them.

You could swap "our menu system" and ".desktop files" here and your
argument would still be about as valid.

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


signature.asc
Description: Digital signature

Re: [custom] Debian Enterprise - packages

[David Palmer]

On Thu, 2003-12-04 at 19:58, Russell Coker wrote:
> On Thu, 4 Dec 2003 16:44, "David Palmer." <[EMAIL PROTECTED]> wrote:
> > On Thu, 2003-12-04 at 07:04, Russell Coker wrote:
> > > Please point out where the Adamantix developers expressed a willingness
> > > to help in any way.
> 
> That message was intentionally to you not the list.  Now we will have another 
> flame-war.

I'm sorry, but I didn't even notice. I did note that the reply was
addressed to you, but changed it without thinking, because I am always
careful to reply to the list.
I don't think of anything else because I never disguise anything I do
unless I am up against an enemy, and I did not think that this was the
scenario here.

> > I searched the Debian-devel archive for the exchanges I read myself, but
> > do you think that I could find them? No way!
> > They must be there somewhere, but time is short, so I grabbed this off
> > the Adamantix site.
> > I think that it adequately displays Peter Bussers' attitude.

I picked Peters' name off the site because it was the one I remembered
from the debian-devel thread. Frankly I notice no disparity between what
he expressed then and what he has expressed on the site.
> 
> The web site does not seem to match Peter's actions.

I will contact him and inquire about intention in order to establish
what the situation is.
I see absolutely no justification for a flamewar.
May I enquire as to the issue(s) involved?
Regards,

David.

Re: [custom] Debian Enterprise - flavors

[Joerg Wendland]

Zenaan Harkness, on 2003-12-03, 14:58, you wrote:
> To give limits to Debian Enterprise/ User Linux we need to define some
> areas of focus.
> 
> Flavours (and sub-flavours/ tasks/ yadda) is as good a place to start as
> any. So here are some proposed flavours:
> 
>  - Enterprise (base packages and more "neutral" config)
>  - Enterprise Desktop - with sub-flavours of:
> - Secretary Desktop
> - Presentation Client (OO Presenter, multimedia, flash)
> - Developer Desktop (all build-depends of all flavours, as a start)
> 
>  - Enterprise Fileserver
>  - Enterprise Webserver
>  - Enterprise Auth Server
>  - Enterprise Departmental Server (combines File, Web + Auth)
> 
>  - Enterprise Firewall
>  - Enterprise SCM Server
>  - Enterprise Router
> 
>  - Enterprise Thin Client

All these are not that important for real enterprises (talking about
large ones).  What they need, is _one_ enterprise server.  That is an
operating system that has features like distributed file-systems,
high-availability facilities, system health monitoring and CPU-hotplugging ;-)
When such a system is available, then having a "fileserver flavor" is
just a matter of typing "apt-get install samba".  So what I (and my
clients) need is an operating system for the real big boxen.  This is of
course Debian but I expect of Debian Enterprise to bring me an install
CD that will let me setup such a system just like I would setup my
small desktop computer with a standard woody CD.

Joerg

-- 
Joerg "joergland" Wendland
GPG: 51CF8417 FP: 79C0 7671 AFC7 315E 657A  F318 57A3 7FBD 51CF 8417


signature.asc
Description: Digital signature

Re: debsums for maintainer scripts

[Goswin von Brederlow]

"Bernhard R. Link" <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow <[EMAIL PROTECTED]> [031204 02:46]:
> > "Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> > > I don't think so. md5-calculation it not the fastest thing (especially
> > > on non-i386 it often feels like downloading and installing together
> > > needs less time than the md5sum-verification.
> > > So this should be switched off, but then it will be missing when one
> > > needs them.
> > 
> > The md5sum file should be generated at build time, signed and only the
> > signature kept. The signature is small enough not to cause bloat, it
> > can be included in the Package file or a Signatures.gz file containing
> > all signatures could be maintained in the archive.
> 
> That still adds the burden of calculating them all after installing.

Only if you need/want to verify.

> I also think it is hardly possible to regenerate the .md5sums file
> in a way the signature will be kept. It would need to never change
> which files are included and how they are sorted. It could also
> cause problems with more sophisticated Replaces and may bite with
> other things I cannot even think about.

dpkg has a list of all files of each package and they can be easily
sorted.

In theory dpkg-repack should build debs with the same signature. In
praxis the original conffiles are frequently missing, happens when you
have edited the file and never updated after that. Otherwise a
dpkg-orig file is there. But thats fixable and should be fixed anyway
for 3-way diffs.
 
> > > Its also a warm feeling to run debsums to see the broken memory chip
> > > one just replaced with a working one has not caused any bit-changes
> > > in the installed files. If the checksums were created at the same
> > > system, one has to get them from somewhere else, so there is little
> > > sense in having them generated at all.
> > 
> > The signature of the locally generated ones wouldn't match the one in
> > the Packages or Signatures file. If the Packages/Signatures file has
> > been tampered with itself (passed through bad memory) one gets a few
> > false negatives but never (1:874584575... whatever the hash size is
> > there) a false positive.
> 
> Only if there is a reliable way to regenerate them at instalation time.
> And if one decided to save the time to calculate them or save the space
> by freeing the generated .md5sums file, bringing the system back in a
> state where such integrity can be checked is almost equivalent to
> a reinstall, while extracting the classical .md5sums file from an 
> package pool (local mirror, set of CDs ...) and putting them back in
> place is very simple and needs far less processing power.

No, if the originals of the conffile are kept you should be able to
dpkg-repack any deb at any time. Otherwise the deb has been tampered
with (rightfully or not) and not just configured.

You also need to compute the md5sum of all files. Generating a sorted
list of those per package and verifying a signature is hardly more
work than comparing the md5susms file itself. The main burden will be
generating the md5sums in the first place.

You see, you safe the space for the md5sum, you don't waste time (just
the signature verify instead of cmp), everybody downloads less (no
md5sums file in the debs) and you are still more secure and tamper
proof.

MfG
Goswin

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Wouter Verhelst ([EMAIL PROTECTED]) [031203 23:10]:
> > Op wo 03-12-2003, om 10:09 schreef Andreas Barth:
> > > > > 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.
> > > > 
> > > > Valid for the autobuilder the package has been handed to and that send
> > > > it in and if the changes file is correct.
> > > > 
> > > > But what if the buildd failed and someone manually build the deb,
> > > > signes it and uploads? The debian archive scripts would need a way to
> > > > distinguish between autobuild packages and manually build binary-only
> > > > uploads.
> > 
> > I don't see why that would be the case. Could you elaborate?
> >
> > > The archive script would of course continue to accept any deb by any
> > > DD under the same conditions as today. The question to the
> > > buildd-admins is: How often does this happen?
> > 
> > Hardly ever, if at all. Most "manual" bin-NMU's are done by people that
> > are not buildd admins.
> 
> I don't understand what you mean. Perhaps it would be best if I try to
> rephrase my ideas:
> 
> The archive scripts accept a package currently if the following
> conditions are met:
> * There is an signed changes file for the debs by a DD
> 
> These would be harded to the following:
> * There is an signed changes file for the debs by a DD
> * The debs are signed
>   - by an DD
>   or
>   - by an buildd, if this buildd was the one to build this package.

or
- by and buildd and by a DD (or the DD of the buildd)

If we can work the signing part out without making it more work.

> So, the archive scripts don't distinguish between autobuild packages
> and manually build binary-only packages, but they look at the debs,
> and verify the signature. If the signature is by a DD, everything is
> ok. If the signature is by a buildd, they verify that the buildd had
> had an job to build this deb.

That would be nice too I think.

> Ok?

Sounds ok but the upload rules can be tightened much much later. First
we have to get signing started, which means fixing apt-utils or
debsigs or preferably both. And of cause change policy to
allow/suggest it.

MfG
Goswin

买MP3非要去中关村吗 批发商299元

[mp3批发]

 请天津、北京的朋友一定来看看，如果您闲下边文字乱，请您直接点击： 
 http://www.cityxf.com/lan2.htm或; http://www.cityxf.com/eshop   



?  
? 京津MP3、CD数码总批发?  
  ?┤  ├?
  ?? http://www.cityxf.com/eshop  ??
  ???
　?  ?
　?批发商（蓝点数据公司）的优势：?
  ?  ?
  ?   一、 占领天津北京4成批发量，价格全国最低： ?
  ?  ?
  ?鞍山西道（天津）中关村（北京）4成批发来自我们，同一台月光宝盒为例 ?
  ?样图：http://www.cityxf.com/eshop/TrueShop_Goods_Info.asp?id=1232 ?
  ?鞍山西道普通柜台出货的价大约在550元（杂牌、质量差）--900元，我?
  ?们的价基本上要便宜100元左右，因为我们是批发商，因为我们是网络直   ?
　?销，无税金、无租店费等，成本让利给广大消费者。?
  ?  ?
  ?   二、售后好，服务到位！ ?
  ?  ?
  ?  一般普通客户的维修问题，直接拿回我们总公司来，1--2天?
  ?就可以解决。如果遇到更换配件的问题，我们一般都打回原厂，一周就?
  ?可以解决。我们从不对客户玩虚的，不象某些商家承诺终生免费保修，这  ?
  ?根本是不可能的，如果客户回头找他们，多数时候他们都不认帐，或拖着  ?
  ?赖着。我们真诚的向客户保证，我们所售的一切商品都5天内可以换货，1  ?
  ?月内全免费保修，3年免费维修（不包配件）。 ?
  ?  ?
  ?   三、批发转型零售、随时服务、随意试听： ?
  ?  ?
  ?  从今年的情况和明年的情况来看，数码商品的赢利越来越薄，  ?
  ?专做批发已经基本没什么好处，从今年开始，公司从事零售业务，在总公  ?
  ?司设立“数码试听实验室”，随时欢迎广大天津朋友来试听。?
  ?（蓝点数据地址：地址：天津市河西区卫津南路21号新金龙大厦北10楼）  ?
  ?（天塔以南，体院北“美膳酒楼”旁，8、12、832“环湖中道”下）  ?
  ?电话022-23010232  23370698 13821268671QQ：180936359   ?
  ?  ?
  [EMAIL PROTECTED]   ?
  ?网络商店: http://www.cityxf.com/eshop ?
  ?  ?
  ?  ?
  ?本期力推一款特价批发MP3!  ?
  ?“月光宝盒”直插499元!随便问!全国最低，鞍山西道赛博参考价599元!   ?
  ? 具体图样资料请点击： ?
  ? http://www.cityxf.com/eshop/TrueShop_Goods_Info.asp?id=1232  ?
  ?  ?
  ?  1   最新流行“U盘直插”款式，MP3、WMA等格式全兼容播放。 ?
  ?  2   即插即用、快速传输、分享无间隔  ?
  ?  3   蓝色背光、绚丽迷人。?
  ?  4   中文歌名显示，操作简单易学  ?
  ?  5   128M超大容量存储，尽纳爱乐之心  ?
  ?  6   移动U盘功能，随意存储   ?
  ?  7   超长高品质录音，真实记录生活乐趣?
  ?  8   仅一节7号电池，就可以播放12小时以上 ?
  ?  9  “月光宝盒”型，时尚灵巧，闪现个性锋芒   ?
  ?  ?
  ?**天津数码随身听批发商“蓝点数据”简介：  ?
  ?  蓝点数据从1993年开始专业从事各种名牌数码随身听商品在天津的批?
  ?  发、零售、维修一体化服务，至今已经占有天津6成市场批发分额， ?
  ?  具有雄厚的售后保障实力，技术咨询水准。  ?
  ?  ?
  ?  ?
  ?发扬名牌品质沿袭严谨风格  ?
  ?  ?
  ?  ?
  ?  地址：天津市河西区卫津南路21号新金龙大厦北10楼（天塔以南，体?
  ?  院北“美膳酒楼”旁，乘公交车8路、12路、832路“环湖中道”下）?
  ?  网络商店地址:http://www.cityxf.com/eshop?
  ?  ?
  ?  [EMAIL PROTECTED]?
  ?  或加入我们公司的QQ：180936359 您会惊奇的发现――您将在24小时?
  ?  内接到热情的客户服务 义务解答您的任何问题   ?
  ?  **如果您愿意屈尊打个电话 022-23010232 23370698  ?
  ?  询问我公司产品 我们将诚实的为您提供全   ?
  ?  国最优价格服务（因本公司完善的售后服务成本，致使相关产品也许?
  ?  不能保证全国最低）  ?
  ?  **如果您愿意把这封邮件推荐给您的朋友，我们保证本公司的服务，?
  ?  会为您作为朋友的形象增光益彩，其中必显示您不凡的品味与眼光。?
  ?  **最后，很抱歉这封广告信打扰了您的正常工作. ?
  ?  ?
  ?  ?
  ?  ?
  ? QQ：180936359 52235884   ?
  ?   http://www.cityxf.com/eshop?
  ? http://www.cityxf.com/lan1.htm   ?
  ??───??
  ?┤   先锋数码坊  http://www.cityxf.com/eshop├?
?───?  



※◇※◆※◇※◆※◇※◆※◇※◆※◇※◆※◇※◆※◇※◆※◇※◆◆※◇※◆※◇※◆

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Raphael Goulais]

On Thursday 04 December 2003 13:19, Andrew Suffield wrote:
> > The silly question is : What does our actual menu system provide that
> > shouldn't be achieved by using .desktop file ?
> >
> > As those are going to be a standard, we should deal with them.
>
> You could swap "our menu system" and ".desktop files" here and your
> argument would still be about as valid.

it was really a question, not an argument. My personal opinion here is that 
adopting standards enabled by freedesktop.org could be good, because 
upstreams seem to adopt them :)

I lack the technical knowledge about .desktop files and debian menu system 
that could allow me to have a real good opinion on the subject. Hence the 
question : Where are the real differences ?

.destop files advantage(s) :

 - well integrated with upstream desktops
 - i18n enabled
 - supported by freedesktop.org
 - ...

debian menu advantage(s) :

 - well integrated into debian :)
 - ...

Please, fill the blanks :)

The other question is "how hard could it be to adapt menu to desktop files ?".

Raphael

Re: Revival of the signed debs discussion

[Andreas Barth]

* Goswin von Brederlow ([EMAIL PROTECTED]) [031204 15:10]:
> Andreas Barth <[EMAIL PROTECTED]> writes:

> > Ok?
 
> Sounds ok but the upload rules can be tightened much much later. First
> we have to get signing started, which means fixing apt-utils or
> debsigs or preferably both. And of cause change policy to
> allow/suggest it.

I want to know before going on a trip where this trip is suggested to
end. Of course, after knowing, we should really start with the first
steps. And these are, as you say:
- Fix apt-utils
- Sign md5sum-files instead of the concatenated binaries (to allow for
  reomte signing)
- Change policy

And don't forget: Start to sign as soon as the toolchain is ready for
it.


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: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Jonathan Dowland]

On Thu, Dec 04, 2003 at 03:53:54PM +0900, Miles Bader wrote:
> Sebastien Bacher <[EMAIL PROTECTED]> writes:
> > I'm not sure that's a good idea. I'm using Gnome and I'd like to keep a
> > simple applications' menu, not having hundred entries like in my
> > debian's menu. Having too many entries in a menu is an usability problem
> > imho 

Does turning on menu hints help?

> I think dropping the current `auto add' behavior of menus would be a
> _serious_ mistake.

Agreed. The debian menu system is imperfect, but has some good features.
The .desktop system is not a direct competitor either, as I understand
it. '.desktop' is also a fairly bad name for a menu convention imho :-)

It has been bashed around a lot but I think the menu system needs to be
discussed thoroughly, as everyone seems to have reserved opinions on how
it should be developed. I would very much like to be involved in an
all-encompassing discussion of how it could be improved. Does anyone
else feel this is a good idea?

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

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow ([EMAIL PROTECTED]) [031204 15:10]:
> > Andreas Barth <[EMAIL PROTECTED]> writes:
> 
> > > Ok?
>  
> > Sounds ok but the upload rules can be tightened much much later. First
> > we have to get signing started, which means fixing apt-utils or
> > debsigs or preferably both. And of cause change policy to
> > allow/suggest it.
> 
> I want to know before going on a trip where this trip is suggested to
> end. Of course, after knowing, we should really start with the first
> steps. And these are, as you say:
> - Fix apt-utils

Patch existing.

> - Sign md5sum-files instead of the concatenated binaries (to allow for
>   reomte signing)

That would be a design change in debsigs and debsigs-verify. Small
one. Afaik its still being looked into splitting gpg itself for remote
signing. The md5sum-file signing would be much simpler though.

> - Change policy
> 
> And don't forget: Start to sign as soon as the toolchain is ready for
> it.

I made a little mirror with signed debs. Without preconfiguring or
with the one line patch to apt-utils it works fine. I'm was working on
a debsigs patch for more conform debs, actually a dar (debian ar or
deb ar) binary that supports deb archive ar files as far as debsigs
needs it, when the new opteron arrived. New toys allways distract.

MfG
Goswin

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

[Jonathan Dowland]

On Wed, Dec 03, 2003 at 08:19:24AM +0100, Goswin von Brederlow wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
> 
> > ... apt-get build-dep somesourcepackage" ...
> 
> apt-get build-deb ...

Just to clarify, build-dep is the proposed action rather than build-deb?

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

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

[Jonathan Dowland]

On Wed, Dec 03, 2003 at 06:10:27PM +1100, Hamish Moffatt wrote:
> On Tue, Dec 02, 2003 at 02:10:56PM +, Jonathan Dowland wrote:
> > 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.
> 
> Yes, and "apt-get build-dep somesourcepackage" does install the
> necessary build-deps, so this fits right in.

Ah yes, of course. I was thinking of an action which would return build
dependencies, not install them. For the latter case apt-get would be the
logical tool.

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

Re: Bits from the RM

[Peter S Galbraith]

"Nikita V. Youshchenko" <[EMAIL PROTECTED]> 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.
> 
> Doesn't this mean that "non-release critical bug in another package" should 
> become release critical?

It has happenned, and I disagreed.  I remember when Imagemagick's
`convert' failed to convert certain files to certain other types.  The
`convert' binary is one of many in Imagemagick and it worked correctly
for the vast majority of cases.  But another package's was using convert
in the build stage to convert some images and it was failing.  The bug
was elevated to release-critical.  I don't think it would be fair to
remove imagemagick from the distribution for such a case.

Peter

Re: Bits from the RM

[Peter S Galbraith]

Anthony Towns  wrote on debian-devel-announce:

>   I think the best way is to
> file a RFA (which we're redefining as "Request For Assistance" instead
> of just "Request For Adoption") report against wnpp
[cut]
> Third, personnel deployment. As a complement to the "Request For
> Assistance" stuff, we're also creating a new wnpp heading, OTA for
> "Offer To Assist".

Will http://www.debian.org/devel/wnpp/ be modified to reflect these new
tags?  (When it's official I'll modify debian-bug.el)

Does the OTA bug get filled against the package you are offering to help
with, or against wnpp?  I presume against the package you are offering
to help with, but then there's no easy way to see where help is offered
overall.

Thanks,
Peter

Bug#222894: ITP: dap -- Comprehensive audio sample editing and processing suite

[Eric Van Buggenhaut]

Package: wnpp
Severity: wishlist

* Package name: dap
  Version : 2.1.5
  Upstream Author : Richard Kent <[EMAIL PROTECTED]>
* URL : http://www.cee.hw.ac.uk/~richardk/
* License : GPL
  Description : Comprehensive audio sample editing and processing suite

DAP is a comprehensive audio sample editing and processing suite. DAP
currently supports AIFF, AIFF-C, WAV and RAW audio files, 8 or 16 bit
resolution and 1, 2 or 4 channels of audio data. Note however that
compressed
AIFF-C files are not currently supported, only non-compressed AIFF-C
files.

The package itself offers comprehensive editing, playback and recording
facilities including full time stretch resampling, manual data editing
and a
reasonably complete DSP processing suite.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux femto 2.6.0-test11 #3 Sat Nov 29 05:05:05 CET 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL 
PROTECTED])

Re: debsums for maintainer scripts

[Manoj Srivastava]

On Wed, 3 Dec 2003 23:19:58 +0100, Bernhard R Link <[EMAIL PROTECTED]> said: 

> * Manoj Srivastava <[EMAIL PROTECTED]> [031203 20:12]:
>> Before we make such a push, we should at least ensure that it is
>> something we really want to do. I think locally generated checksums
>> are a better solution.

> I don't think so. md5-calculation it not the fastest thing
> (especially on non-i386 it often feels like downloading and
> installing together needs less time than the md5sum-verification.
> So this should be switched off, but then it will be missing when one
> needs them.

That is but one optimization: we already are suffering from
 archive bloat, what about the disk and bandwidth cost of carrying
 around the sigs?  And since one rarely needs the md5sums anyway, what
 is so wrong with checking against the .deb when needed?

Verifying the local install requires a calculation of md5sum
 for every file installed. Not something you want to do, then, if
 md5sum calculation takes a long time.

> Not having some host-specific automatism makes it also much easier
> to verify them. A kernel together with some

There is nothing preventing us from standardizing the
 automation mechanism, and building tools on top of that.

> mount-md5sum-cruft-debsums utility may fit together with the md5sums
> of the .md5sums files on a floppy. If those files may look
> different, one may need to include those files as well. (And
> extracting them from some package pool is also more complicated).

Why is it more complicated?  Here, try this:
__> ar p  
/usr/local/src/arch/packages/debian--0.1/mailagent/mailagent_3.73-9_i386.deb 
data.tar.gz | tar zfd -
./usr/bin/mailpatch: Mod time differs
./usr/bin/mailhelp: Mod time differs
./usr/bin/maillist: Mod time differs
./usr/bin/maildist: Mod time differs
./usr/bin/package: Mod time differs
./usr/bin/edusers: Mod time differs
./usr/bin/mailagent: Mod time differs
./usr/share/mailagent/chkagent.sh: Mod time differs
./usr/share/mailagent/filter.sh: Mod time differs
./usr/share/mailagent/setup.cf: Mod time differs
./usr/share/mailagent/mailagent.cf: Mod time differs
./usr/share/mailagent/commands: Mod time differs
./usr/share/man/man1/maillist.1.gz: Mod time differs
./usr/share/man/man1/maillist.1.gz: Contents differ   <-
./usr/share/man/man1/mailhelp.1.gz: Mod time differs

How difficult was that?

__> ar p  
/usr/local/src/arch/packages/debian--0.1/mailagent/mailagent_3.73-9_i386.deb \
data.tar.gz | tar zfd - | grep 'Contents differ'
./usr/share/man/man1/maillist.1.gz: Contents differ
./usr/share/man/man1/mailhelp.1.gz: Contents differ
./usr/share/man/man1/mailpatch.1.gz: Contents differ
./usr/share/man/man1/package.1.gz: Contents differ
./usr/share/man/man1/edusers.1.gz: Contents differ
 ...

Heck, seems like this is simpler than futzing around with
 checksums. 


> Its also a warm feeling to run debsums to see the broken memory chip
> one just replaced with a working one has not caused any bit-changes
> in the installed files. If the checksums were created at the same
> system, one has to get them from somewhere else, so there is little
> sense in having them generated at all.

A warm fuzzy feeling, however, is to be distrusted when
 dealing with security and/or system integrity checking.

manoj
-- 
Engineering: "How will this work?" Science: "Why will this work?"
Management: "When will this work?" Liberal Arts: "Do you want fries
with that?"
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: debsums for maintainer scripts

[Manoj Srivastava]

On 04 Dec 2003 02:44:31 +0100, Goswin von Brederlow <[EMAIL PROTECTED]> said: 

> "Bernhard R. Link" <[EMAIL PROTECTED]> writes:
>> * Manoj Srivastava <[EMAIL PROTECTED]> [031203 20:12]:
>> >Before we make such a push, we should at least ensure that it
>> >  is something we really want to do. I think locally generated
>> >  checksums are a better solution.
>>
>> I don't think so. md5-calculation it not the fastest thing
>> (especially on non-i386 it often feels like downloading and
>> installing together needs less time than the md5sum-verification.
>> So this should be switched off, but then it will be missing when
>> one needs them.

> The md5sum file should be generated at build time, signed and only
> the signature kept. The signature is small enough not to cause
> bloat, it can be included in the Package file or a Signatures.gz
> file containing all signatures could be maintained in the archive.

Good, except that now we have no checksum checks for the most
 critical files on my system -- the ones that tailor all software that
 runs to my environment. Generating the md5sums on install for atleast
 the conffiles should still be considered, since the checksums for the
 conffiles on my system often bear little resemblance to the md5sums
 for the conffiles shipped with the package.

> When one needs to verify the md5sum files can be generated
> (dpkg-repack and then generate them) and compared.

Why dpkg-repack?
__> cat /var/lib/dpkg/info/mailagent.list | while read i; do test -f $i \
   md5sum $i; done
c1188623038c4ae8b0b94b7718ed33d4  /usr/bin/mailpatch
448fa9faf25a526231944b5c19d85305  /usr/bin/mailhelp
21da2125bd7dd23885b4ae929187b6a4  /usr/bin/maillist
ffd68a1d6b7e8cc3bf20466fb37ef03d  /usr/bin/maildist
c709fd09363185e556c64be2c81ff6fb  /usr/bin/package
39437a68a2dc5501b3fc37458219fcc8  /usr/bin/edusers
66dbd5e38b2c05241b103db274399576  /usr/bin/mailagent
 

> Or the files can be generated at install time and stored
> too. Intrusion detection systems could use those files then since
> the signature preventstampering. It would be the users choice.

manoj
-- 
Now she speaks rapidly.  "Do you know *why* you want to program?" He
shakes his head.  He hasn't the faintest idea. "For the sheer *joy* of
programming!" she cries triumphantly.  "The joy of the parent, the
artist, the craftsman.  "You take a program, born weak and impotent as
a dimly-realized solution.  You nurture the program and guide it down
the right path, building, watching it grow ever stronger.  Sometimes
you paint with tiny strokes, a keystroke added here, a keystroke
changed there."  She sweeps her arm in a wide arc.  "And other times
you savage whole *blocks* of code, ripping out the program's very
*essence*, then beginning anew.  But always building, creating,
filling the program with your own personal stamp, your own quirks and
nuances.  Watching the program grow stronger, patching it when it
crashes, until finally it can stand alone -- proud, powerful, and
perfect.  This is the programmer's finest hour!"  Softly at first,
then louder, he hears the strains of a Sousa march.  "This ... this is
your canvas! your clay!  Go forth and create a masterwork!"
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: debsums for maintainer scripts

[Manoj Srivastava]

On Thu, 4 Dec 2003 13:02:57 +0100, Bernhard R Link <[EMAIL PROTECTED]> said: 

> * Goswin von Brederlow <[EMAIL PROTECTED]>
>   [031204 02:46]:
>> "Bernhard R. Link" <[EMAIL PROTECTED]> writes:
>> > I don't think so. md5-calculation it not the fastest thing
>> > (especially on non-i386 it often feels like downloading and
>> > installing together needs less time than the md5sum-verification.
>> > So this should be switched off, but then it will be missing when
>> > one needs them.
>>
>> The md5sum file should be generated at build time, signed and only
>> the signature kept. The signature is small enough not to cause
>> bloat, it can be included in the Package file or a Signatures.gz
>> file containing all signatures could be maintained in the archive.

> That still adds the burden of calculating them all after installing.
> I also think it is hardly possible to regenerate the .md5sums file
> in a way the signature will be kept. It would need to never change
> which files are included and how they are sorted. It could also
> cause problems with more sophisticated Replaces and may bite with
> other things I cannot even think about.

Simple: we already store the lists of files in a package; use
 that to regenerate the file. I mean,  you are assuming thet
 /var/lib/dpkg/info has been uncorrupted, after all.

> Only if there is a reliable way to regenerate them at instalation
> time.

Sure there is. (Just tested -- I regenerated a file several
 times in a row like so: cat /var/lib/dpkg/info/mailagent.list | while
 read i; do test -f $i && do j=$(md5sum $i); done).

> And if one decided to save the time to calculate them or save the
> space by freeing the generated .md5sums file, bringing the system
> back in a state where such integrity can be checked is almost
> equivalent to a reinstall, while extracting the classical .md5sums
> file from an package pool (local mirror, set of CDs ...) and putting
> them back in place is very simple and needs far less processing
> power.

If you have the .debs available, is it not simpler to just do:
__> ar p \

/usr/local/src/arch/packages/debian--0.1/mailagent/mailagent_3.73-9_i386.deb \
data.tar.gz | tar zfd - | grep 'Contents differ'

?

manoj
-- 
No, that'd be silly. Larry Wall in <[EMAIL PROTECTED]>
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Revival of the signed debs discussion

[Matt Zimmerman]

On Thu, Dec 04, 2003 at 03:03:39AM +0100, Goswin von Brederlow wrote:

> Signed debs establish a trust chain from the buildd to the user and
> from the buildd-admin/maintainer to the user as well as copy the
> existing trust chain from ftp-master to the user into the deb itself.
> 
> The Release.gpg only protects against a mirror being hacked. Checking
> it is important but not as powerfull as a signature in the deb.

This sounds backwards.

Release signing protects against a hostile or compromised mirror, network,
DNS server, proxy server, and a host of other, similar attacks, and also
prevents most forms of the "substitute old, vulnerable packages" attack.

What kind of real world attacks do signed debs prevent?  Not a compromised
buildd, or a compromised maintainer's workstation.

-- 
 - mdz

Re: debsums for maintainer scripts

[Thomas Viehmann]

Manoj Srivastava wrote:
>   Before we make such a push, we should at least ensure that it
>  is something we really want to do. I think locally generated
>  checksums are a better solution.
To me, the main use of md5sums seems to be verifying nothing bad (as in
accident, not malicious manipulation) happened to the extracted files.
md5sums included in the packages do that even earlier than those generated.

Cheers

T.


pgpXtF4sE6N8L.pgp
Description: PGP signature

Re: Bits from the RM

[Frank Lichtenheld]

On Thu, Dec 04, 2003 at 10:38:10AM -0500, Peter S Galbraith wrote:
> Anthony Towns  wrote on debian-devel-announce:
> 
> >   I think the best way is to
> > file a RFA (which we're redefining as "Request For Assistance" instead
> > of just "Request For Adoption") report against wnpp
> [cut]
> > Third, personnel deployment. As a complement to the "Request For
> > Assistance" stuff, we're also creating a new wnpp heading, OTA for
> > "Offer To Assist".
> 
> Will http://www.debian.org/devel/wnpp/ be modified to reflect these new
> tags?  (When it's official I'll modify debian-bug.el)

It is simple to do this and I also offered to do it for another proposal
one day before the compromise. When I regain CVS access I can/will take 
care of it.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/

Bug#222899: ITP: djohn -- Distributed password cracker

[Samuele Giovanni Tonon]

Package: wnpp
Severity: wishlist

  Package name: djohn
  Version : 0.9.8.1
  Upstream Author : Luis Parravicini [EMAIL PROTECTED]
  URL : http://ktulu.com.ar/en/djohn.php
  License : GPL
  Description : Distributed password cracker

This is a little program to parallelize brute force
cracking done with John the Ripper [http://www.openwall.com/john].
The cracking in itself is done by John The Ripper and djohn's server
(djohnd) divides the work in work packets and coordinates the effort
among the clients (djohn), which are the ones who do the work.


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux cthugha 2.4.21 #4 Fri Sep 5 14:17:17 CEST 2003 i686
Locale: [EMAIL PROTECTED], LC_CTYPE=C


-- 
While various networks have become deeply rooted, and thoughts have been sent
out as light and electrons in a singular direction, this era has yet to 
digitize/computerize to the degree necessary for individuals to become 
a singular complex entity.
  KOUKAKU KIDOUTAI Stand Alone Complex

Re: debsums for maintainer scripts

[Bernhard R. Link]

* Manoj Srivastava <[EMAIL PROTECTED]> [031204 18:00]:
> >> The md5sum file should be generated at build time, signed and only
> >> the signature kept. The signature is small enough not to cause
> >> bloat, it can be included in the Package file or a Signatures.gz
> >> file containing all signatures could be maintained in the archive.
> 
> > That still adds the burden of calculating them all after installing.
> > I also think it is hardly possible to regenerate the .md5sums file
> > in a way the signature will be kept. It would need to never change
> > which files are included and how they are sorted. It could also
> > cause problems with more sophisticated Replaces and may bite with
> > other things I cannot even think about.
> 
>   Simple: we already store the lists of files in a package; use
>  that to regenerate the file. I mean,  you are assuming thet
>  /var/lib/dpkg/info has been uncorrupted, after all.

Ok, I overlooked it. That would give at least a well-defined ordering
of the files for generating the md5sums at installation time. It's still
not possible to generate them later. Making this to work with things
like #184635

> > Only if there is a reliable way to regenerate them at instalation
> > time.
> 
>   Sure there is. (Just tested -- I regenerated a file several
>  times in a row like so: cat /var/lib/dpkg/info/mailagent.list | while
>  read i; do test -f $i && do j=$(md5sum $i); done).

# for n in `sort /var/lib/dpkg/info/*.list | uniq -d` ; do test -f $n &&
echo $n ; done | wc -l
  16

 
>   If you have the .debs available, is it not simpler to just do:
> __> ar p \
> 
> /usr/local/src/arch/packages/debian--0.1/mailagent/mailagent_3.73-9_i386.deb \
> data.tar.gz | tar zfd - | grep 'Contents differ'

Well, there is a reason debsums does more then just comparing the files
listed in the .md5sums with the files at the given locations.
There are packages replacing files of other packages. There are
diversions and possible other uglyness.

I also prefer to have the .debs in local mirrors and not at each
indiviual host. And just extracting the .md5sums and copying
is much less hassle, then sending all the files at whole over the
network.

Hochachtungsvoll,
  Bernhard R. Link

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

Re: debsums for maintainer scripts

[Bernhard R. Link]

* Goswin von Brederlow <[EMAIL PROTECTED]> [031204 15:05]:
> > I also think it is hardly possible to regenerate the .md5sums file
> > in a way the signature will be kept. It would need to never change
> > which files are included and how they are sorted. It could also
> > cause problems with more sophisticated Replaces and may bite with
> > other things I cannot even think about.
> 
> dpkg has a list of all files of each package and they can be easily
> sorted.

They can be easily sorted, after you decided how to sort. I have no
problems to imagine that filename may have more than just ascii
characters in the near future or that some sorting rotine may be
depending on a given locale and other things. This one (other file
due to different sorting) is the least propable of the three possible
reasons I mentioned. And things like that have bitten us in other
situations already...

> In theory dpkg-repack should build debs with the same signature. 

Well, I prefer theories whose results agree with reality:
# ar -p ~admin/blub_1.00-1_i386.deb data.tar.gz | tar -tzf - ./gaga/dada
./gaga/dada
# dpkg -i ~admin/blub_1.00-1_i386.deb
# cat /gaga/dada
a
# dpkg -i ~admin/bla_1.00-1_i386.deb
# cat /gaga/dada
b
# dpkg-repack blub
dpkg-deb: building package 'blub' in './blub_1.00-1_i386.deb'.
# ar -p ./blub_1.00-1_i386.deb data.tar.gz | tar -tzf - ./gaga/dada
tar: ./gaga/dada: Not found in archive.
tar: Error exit delayed from previous errors.

Both 'blub' and 'bla' are just made by dh_make with an 
mkdir debian//gaga/dada
echo  > debian//gaga/dada
instead of $(MAKE) install in debian/rules and debian/control of
'bla' habing an additonal Replace: blub in it.

> In
> praxis the original conffiles are frequently missing, happens when you
> have edited the file and never updated after that. Otherwise a
> dpkg-orig file is there. But thats fixable and should be fixed anyway
> for 3-way diffs.

I'd really prefer to have a working solution in favour of one, that
starts to be to be fixes and is like to continue to be so.

> > Only if there is a reliable way to regenerate them at instalation time.
> > And if one decided to save the time to calculate them or save the space
> > by freeing the generated .md5sums file, bringing the system back in a
> > state where such integrity can be checked is almost equivalent to
> > a reinstall, while extracting the classical .md5sums file from an 
> > package pool (local mirror, set of CDs ...) and putting them back in
> > place is very simple and needs far less processing power.
> 
> No, if the originals of the conffile are kept you should be able to
> dpkg-repack any deb at any time. Otherwise the deb has been tampered
> with (rightfully or not) and not just configured.

But I do not want to know, if the packages have been tempered with.
(Especially as the package management explicitly supports this), but
I want to know which "files" have changes. Generating the .md5sums file
locally is - if at all - only possible at installation time. So either
I have to run the md5sum calculation with any package beeing installed,
or almost no possibility to get later in that state.

> You also need to compute the md5sum of all files. Generating a sorted
> list of those per package and verifying a signature is hardly more
> work than comparing the md5susms file itself. The main burden will be
> generating the md5sums in the first place.

No. I have no reason at all to generate the md5sum until I want to check
the files. At installation time tar already checks for transmitting
errors. 

> You see, you safe the space for the md5sum, 

Huh?

# cat /var/lib/dpkg/info/*.md5sums | wc -c
9165770
# df -h /usr
/dev/hda2  27G  2.6G   23G  10% /usr

And the count of packages not having md5sums does not save you here:
# ls /var/lib/dpkg/info/*.list | wc -l
   1157
# ls /var/lib/dpkg/info/*.md5sums | wc -l
988

> you don't waste time (just
> the signature verify instead of cmp), everybody downloads less (no
> md5sums file in the debs) and you are still more secure and tamper
> proof.

All I see is waste of time, less security and enough complexity that
it is bound to fail. And that compared to an existing, working and
robust solution that only needs the last some packages to follow.
And your only reason beeing a ridiculous small amount of
disc space and bandwidth)

Hochachtungsvoll,
  Bernhard R. Link

BTW: I don't need your mails twice. Please do either send to me or 
the list and not both. Thank you.

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

Re: Two different libpng2_1.0.12-3.woody.3_i386.deb?

[Jeroen van Wolffelaar]

On Wed, Dec 03, 2003 at 02:46:59PM -0600, Chad Walstrom wrote:
> On Wed, Dec 03, 2003 at 06:30:16PM +0100, Jeroen van Wolffelaar wrote:
> > On Wed, Dec 03, 2003 at 05:44:36PM +0100, Santiago Vila wrote:
> > > file=main/libp/libpng/libpng2_1.0.12-3.woody.3_i386.deb
> > > wget -q -O 1.deb http://ftp.debian.org/debian/pool/$file
> > > wget -q -O 2.deb http://security.debian.org/pool/updates/$file
> > > diff 1.deb 2.deb
> > 
> > > Binary files 1.deb and 2.deb differ
> 
> The security archive are updates to the stable archive.  The stable
> archive does not get updated on a regular or even semi-regular basis.
> It only gets updated periodically, when a new release of stable is made.
> This is a very formal event.  Updates that have accumulated in the
> security archive may be moved over into the standard archive at this
> time.  Otherwise, they do not intermingle.

This does explain why on stable sometimes packages are more outdated
than on security (because there has been no point release since).

But this does not explain why it can happen that there are _two
different_ versions of the _exactly same_ version of a package. This is
i.m.h.o. a bit strange.

> If in doubt, use the latest stable debian version of the software,
> regardless of which archive (security or standard) it comes from.

It isn't 'regardless' since they are different (though only in gzip
compression)

--Jeroen

-- 
Jeroen van Wolffelaar
+31-30-253 4499
[EMAIL PROTECTED]
http://Jeroen.A-Eskwadraat.nl


pgp92ydJKWYPB.pgp
Description: PGP signature

Re: [RFC] adding system users: which is the best way??

[Anthony DeRobertis]

On Dec 3, 2003, at 22:35, Graham Wilson wrote:
On Wed, Dec 03, 2003 at 10:20:14AM -0500, Anthony DeRobertis wrote:
Please, please, use debian- or some other prefix! That shouldn't 
confuse
any rational person
What about sys- as a prefix?
I'm not particularly tied to any prefix, though something generic like 
'sys' is more likely to cause conflicts than 'debian', I'd think.

'sys' or maybe 'system' would be more appropriate for standardization, 
however.

Re: debsums for maintainer scripts

[Manoj Srivastava]

On Wed, 03 Dec 2003 17:40:51 -0500, Anthony DeRobertis <[EMAIL PROTECTED]> 
said: 

> On Wed, 2003-12-03 at 05:23, Manoj Srivastava wrote:
>> Because it buys little security wise?

> I can take a rescue disk, a CD with relevant packages on it, boot
> the suspect server from the rescue disk, and quickly check
> md5sums. At least, if all packages had md5sums I could.

Heh. You got the debs, you don't need the md5sum trickery. Try
 something like this:

__> ar p  
/usr/local/src/arch/packages/debian--0.1/mailagent/mailagent_3.73-9_i386.deb 
data.tar.gz | tar zfd - | grep 'Contents differ'

With the appropriate .deb, of course. Doing this with
 the control tar is left as an exercise for the reader.

manoj
-- 
"I believe the use of noise to make music will increase until we reach
a music produced through the aid of electrical instruments which will
make available for musical purposes any and all sounds that can be
heard." composer John Cage, 1937
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: debsums for maintainer scripts

[Anthony DeRobertis]

On Dec 3, 2003, at 21:07, Goswin von Brederlow wrote:
You can just as well just check all the debs. gunzip doesn't take
longer, the slowest thing usually is the cdrom.
True, so I should probably just put the md5sums files on my CD, and 
check those. That'd be far faster.

I could even put the md5sums on a floppy, they're small. Or md5sums for 
all packages, even.

Actually, I think the biggest benefit of md5sums is that while 
attackers certainly could modify them, often they don't. While passing 
debsums certainly can't prove the integrity of a system, debsums 
failing can certainly prove the lack of integrity.

And they do help when you suspect hardware troubles, too.

Re: debsums for maintainer scripts

[Manoj Srivastava]

On Thu, 4 Dec 2003 02:29:29 +0100, Javier Fernández-Sanguino Peña <[EMAIL 
PROTECTED]> said: 

> On Wed, Dec 03, 2003 at 04:23:33AM -0600, Manoj Srivastava wrote:
>> On Mon, 1 Dec 2003 17:12:36 -0500, christophe barbe
>> <[EMAIL PROTECTED]> said:
>>
>> > I don't see why adding a md5dsum_are_mandatory clause to the
>> > debian policy would be difficult (what would be a good reason to
>> > not add md5sum to a package?).
>>
>> Because it buys little security wise? Because there are solutions
>> one can put in place today that offer better coverage than in
>> package md5sums?

> First off, little security is better than no security.

I can turn that around and say that a false sense of security
 is worse than a paranoid admin knowing there is no real security.

> Second, it's not only useful for security, it's useful for integrity
> checking (which is not always related). Third, other solutions
> (calculating md5sums on install, running tripwire/aide, etc.)  might
> be computational intensive and might need to be ruled out in some
> (critical) systems.

How big a domain are we talking about? A mission critical
 system where it is not feasible to compute md5sums, nor maintain a
 cache of installed .debs, nor have access to a faster/non production
 system where md5sums can be calculated?

Why are we basing our design on a small subset like this, and
 ignoring issue of archive bloat and bandwidth consumption that
 impacts an arguably larger set of people?

> Finally, there's one thing md5sums in packages can provide that no
> other solution proposed in this thread can: a database of known good
> signatures [1].

Uhhh -- if this were indeed important, it is easy to generate
 such a list from a known good set of .debs.  Why exactly is
 publishing such a list usefule, and not mere make work?

> Many vendors [2] provide a full list of valid md5sums for their
> operating systems which enables investigators to determine if a file
> belongs to the system or it has been modified.

If you want a list of such files, we have it now. If you want
 to do a security audit, the md5sum is useless.  An integrity check
 could perhaps use this, and most systems would be better off with 
   DPkg::Post-Invoke {
   "debsums --generate=nocheck -sp /var/cache/apt/archives";
   };

> This is very useful in a forensic investigation since it enables a

Bullshit. In a forensic investigation you can't trust on disk
 md5sums; and if you need to download the packages to verify the
 md5sum, you have a better check for integrity:
 # ar p  blah.deb data.tar.gz | tar zfd - | grep 'Contents differ'


> So my vote goes to adding md5sums to policy.

We still don't vote on technical issues, thank god.

manoj
-- 
When in doubt, parenthesize.  At the very least it will let some poor
schmuck bounce on the % key in vi. --Larry Wall in the perl man page
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Bits from the RM

[Jan Nieuwenhuizen]

Peter S Galbraith <[EMAIL PROTECTED]> writes:

> another package's was using convert in the build stage to convert
> some images and it was failing.  The bug was elevated to
> release-critical.  I don't think it would be fair to remove
> imagemagick from the distribution for such a case.

>From the other package's view, how fair was it to allow a partly
broken version of Imagemagick enter the distribution, breaking the
build on debian?

Jan.

-- 
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org

Re: debsums for maintainer scripts

[Manoj Srivastava]

On Thu, 4 Dec 2003 12:43:18 +0100, Eduard Bloch <[EMAIL PROTECTED]> said: 

>> include 
> * Manoj Srivastava [Wed, Dec 03 2003, 04:19:59AM]:

>> > - current md5sums file in control.tar.gz should contain checksums
>> >   of
>> >really all files
>>
>> Hard to do for conffiles. Now, if the md5sums were generated

> Then only add the m5sums of the control.tar.gz contents and add it
> to the list created my dh_md5sums.

That does not help at all. I think you have missed the whole
 point: the files that determine program behaviour on the target
 system do not have checksums that can be generated from
 control.tar.gz. 

>> at install time, you could checksum my locally modified conffile
>> (even if I did not accept the maintainers changes). The md5sums
>> stored for conffiles currently are rarely any good, since the files
>> are often modified by the admin.

> This needs more work. I think Debian should archive the original
> versions of conffiles on the target filesystem anyways - the absence
> of them is a handicap for any long-term solution.

What good does checking the original conffiles do when they
 are not looked at by anything?

And how exactly is 
   DPkg::Post-Invoke {
   "debsums --generate=nocheck -sp /var/cache/apt/archives";
   };
 much more work?



>> > - new dpkg version should pickup the signature files and store
>> >   them
>> >either in /var/lib/dpkg/info or in some alternative directory
>>
>> Or you could sign the newly generated md5sum files at install time,
>> complete with the checksums of the locally modified conffiles, and
>> not have to depend on knowing the key of the persons producing the
>> Packages file.

> But then you depend on a key that has stored on the local system -
> and I am not sure whom the user should trust more when the system
> has been compromised. And, as said, it requires additional work
> during the installation.

I think you fail to comprehend the solution I proposed. Where
 did you get the idea the key is on the local machine?

manoj

-- 
No one knows like a woman how to say things that are at once gentle
and deep. Hugo
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: OT: Smartcards and Physical Security

[Manoj Srivastava]

On Wed, 3 Dec 2003 13:34:51 -0800, Tom  <[EMAIL PROTECTED]> said: 

> On Wed, Dec 03, 2003 at 09:26:15AM -0600, Manoj Srivastava wrote:
>> Guess what the median age of a Debian developer is.

> Don't know, don't care.

>> Volunteer organization have dues?

> Yes, I don't know what planet you're from, but on this planet the
> Rotarians, Kiwanas, Civitans, Knights of Columbus, United Way, Red
> Cross, Freemasons, NAACP, and Jerry's Kids all collect money from
> their members.  You still feeling superior?

Snippy, aren't we? Usually it is better to have basic logic
 straight before you try for a mistaken sense of haughtiness. 

Let me see if I can point out the logical flaws in words with
 few syllables. Yes, Red Cross goes out hat in hand; but it is not a
 requiremnt to volunteer at the Red Cross.  Indeed, Red Cross often
 pays people who do the  work -- and goes asking money from others --
 in this case, it would be users like you who would be asked to pay,
 were we to take the red cross paradigm.

Most of the other organizations you talk about are social
 clubs, where you pay for the privilege of inclusion.  I am damned If
 I am going to pay for the privilege of cutting into my sleep and
 leisure time to spen 20+ hours a week slaving away at Debian.

manoj
-- 
Any sufficiently advanced technology is indistinguishable from a
rigged demo.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Andrew Suffield]

On Thu, Dec 04, 2003 at 09:01:27PM +0800, Cameron Patrick wrote:
> On Thu, Dec 04, 2003 at 12:19:28PM +, Andrew Suffield wrote:
> | On Thu, Dec 04, 2003 at 12:34:22AM +0100, Raphael Goulais wrote:
> | > On Wednesday 03 December 2003 21:31, Zenaan Harkness wrote:
> | > > I agree. I would like to see .desktop standard adopted. There have been
> | > > a few threads I have seen so far, and there seems to be some level of
> | > > resistance to the idea.
> | > 
> | > The silly question is : What does our actual menu system provide that 
> | > shouldn't be achieved by using .desktop file ?
> | > 
> | > As those are going to be a standard, we should deal with them.
> | 
> | You could swap "our menu system" and ".desktop files" here and your
> | argument would still be about as valid.
> 
> I don't think that this is the case.  As I understand it, .desktop files
> have the advantage that they are already shipped by a number of upstream
> packages, support i18n better than Debian menus, are supported natively
> by KDE and Gnome, include facilities for providing stuff like generic names
> and are supported by the freedesktop.org folk.

That wasn't his argument. However, it's similar, and the response is
the same: why not simply add these features to the Debian menu system?

Nothing you've described is particularly difficult, or anything that
we haven't done before in different contexts.

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


signature.asc
Description: Digital signature

Re: OT: Smartcards and Physical Security

[Manoj Srivastava]

On Wed, 3 Dec 2003 13:36:58 -0800, Tom  <[EMAIL PROTECTED]> said: 

> On Wed, Dec 03, 2003 at 09:24:07AM -0600, Manoj Srivastava wrote:
>> Heh. Your grasp of the practicality of the situation is slipping.
>> Not only do these guys donate a fairly expensive chunk of billable
>> hours and expertise, they must pay to be able to volunteer?

> Sure, if you care about security.

Not quite as much as all that.  I mean I am satisfied that
 Debian is performing its main, and most important goal and reason
 for being: providing a stable operating environment for my cluster of
 machines, which are slowly converting to running mandatory access
 controls.

As long as the reason of being for debian is satisfied, I
 don't see any reasons to invest in smart cards.

manoj
-- 
A large number of installed systems work by fiat.  That is, they work
by being declared to work. Anatol Holt
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Marc Haber]

On Thu, 04 Dec 2003 10:20:16 +0100, Tore Anderson <[EMAIL PROTECTED]>
wrote:
>* Marc Haber
> > Well, I am only paid to work on the exim4 package if my employer gets
> > to use the package as well. Since we don't want debconf questions to
> > pop up during installation and we found the pre-fabricated -config too
> > inflexible for our needs, -config needs to be split out.
>
>  So I take it you roll your own exim4-config-marchaber or something
> which provides exim4-config?
>
>  If so, that does in no way explain the reasoning behind splitting
> up the default configuration file in a million tiny files, nor why
> simply creating a exim4-base-marchaber with the customized scheme
> isn't adequate for you.

Splitting up the config file in small files was necessary to do
debconf support, which is a Debian requirement.

>- A exim4-base package containing the default debconf scripts,
>  which installs a (monolithic) configuration file.

Please state how you intend to fulfill policy with that approach. Give
code examples.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Marc Haber]

On Thu, 4 Dec 2003 13:43:39 +1000, Anthony Towns
 wrote:
>Maybe an easy way of answering that is to instead answer this: why can't
>you just make the -config package a bunch of files and a script that
>doesn't get executed until the daemon package is installed?

That's a nice idea. The -base init script would only do something if a
daemon is found anyway.

I will look into that this weekend.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: OT: Smartcards and Physical Security

[Manoj Srivastava]

On Wed, 3 Dec 2003 13:36:58 -0800, Tom  <[EMAIL PROTECTED]> said: 

> On Wed, Dec 03, 2003 at 09:24:07AM -0600, Manoj Srivastava wrote:
>> Heh. Your grasp of the practicality of the situation is slipping.
>> Not only do these guys donate a fairly expensive chunk of billable
>> hours and expertise, they must pay to be able to volunteer?

> Sure, if you care about security.

Sure is easy to talk about spend other peoples money, ain't it?

manoj
-- 
I think that all right-thinking people in this country are sick and
tired of being told that ordinary decent people are fed up in this
country with being sick and tired.  I'm certainly not.  But I'm sick
and tired of being told that I am. Monty Python
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: debsums for maintainer scripts

[Javier Fernández-Sanguino Peña]

[Manoj, I'm going to concentrate on this example, it's probably a corner
case and I'm probably digressing here ... oh well]

On Thu, Dec 04, 2003 at 11:17:46AM -0600, Manoj Srivastava wrote:
> > Finally, there's one thing md5sums in packages can provide that no
> > other solution proposed in this thread can: a database of known good
> > signatures [1].
> 
>   Uhhh -- if this were indeed important, it is easy to generate
>  such a list from a known good set of .debs.  Why exactly is
>  publishing such a list usefule, and not mere make work?

Why do we have to make each of our users find a solution to generate this
from a _local_ mirror (or the system's .deb archive which shoulnd't be
trusted in the event of an intrusion) when we could do this ourselves and
provide the results?

It is not that much work and known good databases are really useful in
forensic investigation (see below or read Sleuth Kit informer issue #6,
http://www.sleuthkit.org/informer/sleuthkit-informer-6.html)

> 
> > Many vendors [2] provide a full list of valid md5sums for their
> > operating systems which enables investigators to determine if a file
> > belongs to the system or it has been modified.
> 
>   If you want a list of such files, we have it now. If you want

We have the information, but it needs to be extracted. Not all users/admins 
now how to handle our archive, and there are no standard tools to do what 
I'm askin for (again, see below)

>  to do a security audit, the md5sum is useless.  An integrity check

No it's not, see below.

>  could perhaps use this, and most systems would be better off with 
>DPkg::Post-Invoke {
>"debsums --generate=nocheck -sp /var/cache/apt/archives";
>};


If I want to do a security audit of a compromised system, taken offline, of
which I have a hard disk image, md5sums are _not_ useless. If I have a list
of known good checksums (provided by the vendor) I can compare them with
the files and see what files might have been changed by an intruder. I can
also use them to detect what packages do files belong to and see if the
packages are known to have security holes (i.e. the 'downgrade' case).

Notice that I'm not necessarily depending on the local md5sums, I'm taking
a file provided by a vendor, in this case, Debian. Let's call it
Contents-xxx.md5sum.gz.  This file is available for download from all
Debian mirrors, signed with the Release key and provides these three fields
for every file in a single Release:

filename  md5sum  package

I don't see any reason why we shouldn't provide this and there are some
situations in which it would be useful (see below). In order to do this
we could either:

1) run a task on the mirrors to generate it (extract the files from the 
ars, calculate the md5sum, etc..) when we make a Release
or
2) take the information on the package's md5sums file and put it in a 
single file.

Now, with (2), at the same time, you are giving the users a way to 
check the filesystem locally, i.e.  do integrity checking "online". This 
has several benefits as already described, but even more in the forensic 
situation.

> 
> > This is very useful in a forensic investigation since it enables a
> 
>   Bullshit. In a forensic investigation you can't trust on disk
>  md5sums; and if you need to download the packages to verify the
>  md5sum, you have a better check for integrity:
>  # ar p  blah.deb data.tar.gz | tar zfd - | grep 'Contents differ'

When did I say that I was trusting disk md5sums? I'm trusting the image
copy of the compromised system, the md5sum binaries of the analysis
computer in which the image is stored, and my list of valid md5sums
(downloaded from Debian as described above). I'm not trusting the local 
information on the image copy, but it will be useful to pinpoint attack 
methods easily.

Do you really want to say that the only way a forensic investigator could
have of checking a hard disk image contents is downloading the _full_
Debian archive in order to compare that to the disk? What if the system is
stable+security updates, how would you remove the false positives in your
above example? 

Now, imagine we have this file, and we have the local md5sum database in 
the image copy of the compromise system. I could check rather easily:

1.- if the vendor provided md5sum files in the database matches the local 
md5 hashes information for files in the system.

2.- if the local files's md5 hashes match the local md5sum database. 

3.- if the local files's md5sum match the vendor-provided database and
which packages (even versions, if the database is made of two releases, say
stable and security updates) it belongs to. 

4.- if the packages which files seem to belong to (based on md5sum files)
correspond to packages that _should_ be installed in the system (based on
release files).



Answering (1) can tell me if the local md5 database has been tampered with
or if packages have been modified (they are not the ones provided i

Re: Bits from the RM

[Anthony DeRobertis]

On Dec 4, 2003, at 10:56, Peter S Galbraith wrote:
But another package's was using convert
in the build stage to convert some images and it was failing.  The bug
was elevated to release-critical.  I don't think it would be fair to
remove imagemagick from the distribution for such a case.
More importantly, it'd be quite counterproductive to remove it. But 
having a RC bug does not mean the RM will remove it; indeed, he may 
even chose to 'sarge-ignore' the bug.

Re: Best pratices for short descriptions

[Branden Robinson]

On Sat, Nov 29, 2003 at 10:49:11AM +0100, Florent Rougon wrote:
> Yes. Now, you have the problem that Policy maintainers want
> implementation prior to the rule appearing in Policy and some people
> won't follow rules unless they are stated in Policy (or are themselves
> convinced that the rule is good).

Welcome to the Debian Project.

-- 
G. Branden Robinson|Humor is a rubber sword - it allows
Debian GNU/Linux   |you to make a point without drawing
[EMAIL PROTECTED] |blood.
http://people.debian.org/~branden/ |-- Mary Hirsch


signature.asc
Description: Digital signature

Re: [custom] Debian Enterprise - flavors

[Fabian Fagerholm]

On Thu, 2003-12-04 at 15:20, Joerg Wendland wrote:
> When such a system is available, then having a "fileserver flavor" is
> just a matter of typing "apt-get install samba".
> So what I (and my clients) need is an operating system for the real
> big boxen.  This is of course Debian but I expect of Debian Enterprise
> to bring me an install CD that will let me setup such a system just
> like I would setup my small desktop computer with a standard woody CD.

The way Debian Enterprise has been described, it would provide you with
this option. But you may also want to move "apt-get install samba" and
the related session of tweaking samba's options to suit your network, to
the install phase. Imagine having, for example, a Kerberos/LDAP system
for authentication. Surely the option to install a file server with the
basic configuration for that out of the box would be appealing?

So what you've described is only one aspect of (how I see) Debian
Enterprise.

-- 
Fabian Fagerholm <[EMAIL PROTECTED]>


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

Re: Revival of the signed debs discussion

[Manoj Srivastava]

On Thu, 4 Dec 2003 11:47:50 -0500, Matt Zimmerman <[EMAIL PROTECTED]> said: 

> What kind of real world attacks do signed debs prevent?  Not a
> compromised buildd, or a compromised maintainer's workstation.

It would allow me to copy .debs around with other people, or
 use .debs not made available through the usual chain of security; as
 long as the author hapens to be in my web of trust.

manoj
-- 
When the going gets weird, the weird turn pro. Hunter S. Thompson
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Felipe Almeida Lessa]

> On Thursday 04 December 2003 13:19, Andrew Suffield wrote:
> > > The silly question is : What does our actual menu system provide that
> > > shouldn't be achieved by using .desktop file ?
> > >
> > > As those are going to be a standard, we should deal with them.
> >
> > You could swap "our menu system" and ".desktop files" here and your
> > argument would still be about as valid.
[snip]
> debian menu advantage(s) :
> 
>  - well integrated into debian :)
>  - ...
[snip]
> The other question is "how hard could it be to adapt menu to desktop files ?".

I think only one thing is blocking the whole idea of moving from Debian Menu 
style to freedesktop.org style: the work that need to be done. In other words, 
people don't wanna use the .desktop format because the have already write a 
debian/menu.

It would be *very* hard to make the developers agree, but we need to think in 
the Open Source Community as a whole. The Debian Menu is used only by Debian, 
but the .desktop is or may be used by any distribution. 

Now just imagine what would happen if all the major distributions used a 
standard created by them. We would see Debian Menu, RedHat Menu, Mandrake Menu, 
SuSE Menu, everything in just one upstream package?

IMHO, it's better to make an effort to change all deb's to something approved 
in many places than changing just a few ones to something accepted only here. 
If I said something that sounds like an offense, please forgive me.

Cheers,
Felipe.

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

[Matt Zimmerman]

On Tue, Dec 02, 2003 at 05:19:22PM -0800, Tom wrote:

> Smartcards would have avoided the Debian compromise: merely having a 
> compromised DD box would have prevented bad guy from getting on the box.
> 
> It's all about layers of defense.
> 
> I think the DD's should seriously think about requiring smartcards.  It 
> would have prevented the proxmiate cause of our recent troubles.

You must be joking.  If the developer's system is compromised, and he logs
into another system after that time, that system can be easily compromised
also.

-- 
 - mdz

Re: Revival of the signed debs discussion

[Matt Zimmerman]

On Thu, Dec 04, 2003 at 12:28:41PM -0600, Manoj Srivastava wrote:

> On Thu, 4 Dec 2003 11:47:50 -0500, Matt Zimmerman <[EMAIL PROTECTED]> said: 
> 
> > What kind of real world attacks do signed debs prevent?  Not a
> > compromised buildd, or a compromised maintainer's workstation.
> 
>   It would allow me to copy .debs around with other people, or
>  use .debs not made available through the usual chain of security; as
>  long as the author hapens to be in my web of trust.

What kind of real world attacks do signed debs prevent?

The only one which comes to mind is a rogue Debian developer that you do not
wish to trust, even though the project trusts him.

-- 
 - mdz

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Chad Walstrom]

On Thu, Dec 04, 2003 at 04:49:45PM -0200, Felipe Almeida Lessa wrote:
> I think only one thing is blocking the whole idea of moving from
> Debian Menu style to freedesktop.org style: the work that need to be
> done. In other words, people don't wanna use the .desktop format
> because the have already write a debian/menu.

Then extend the functionality of the Debian menu system to use .desktop
format as both an OPTIONAL target and an optional SOURCE.  Doing so
might ease the burden and barrier to utilizing .desktop files.  It only
stands to reason that if both the KDE and Gnome desktop camps wish to
formalize on the format that we should adopt it as well, if only as an
extension of our menu system.  We would have to generate .desktop files
anyway, when Gnome and KDE move form their own native menu formats.

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


pgpVGrAVUYx4B.pgp
Description: PGP signature

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

[Fabian Fagerholm]

On Thu, 2003-12-04 at 11:42, Zenaan Harkness wrote:
> I could almost cut and paste your email into the wiki it was so clear
> (at least Debian parent(super) project -> CDD -> Flavor).
> 
> I hope I haven't misunderstood you,

No, I was just in a hurry and expressed myself inadequately.

The discussion and presentation of the three layers was, however, just a
step in the process. Now that many people on this list have expressed
their (mostly positive) opinions -- many more could comment still -- and
there has been a proposal of what first actions should be taken -- work
on the Subproject HOWTO -- I think the next set of questions lies ahead.

As Andreas Tille said, and I agree, this borders on a stupid naming
discussion
(http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg00338.html). 
However, there's a reason why it isn't that after all.

Think of these terms as labels or abstract ideas that have a concrete
counterpart -- an implementation, if you will. Mako Hill said of the
2003 Debcamp Custom Distribution BOF:

"I think we left with the idea that "flavors" or "metadistros" and the
like may still describe *technologies* or methods which one could use to
achieve a Custom Distro."
(http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg00367.html)

This is exactly what I was thinking, and I also think that a kind of
understanding about all this has existed for some time. Someone just
needs to s-p-e-l-l it out even when the explanation borders on
stupefaction for those who have already given it lots of thought.

So, mapping the terms "Debian subproject", "Custom Debian Distribution",
and "flavor", to their concrete counterparts, I get:

Debian subproject
  * A group of people.
  * A mission or goal that is a subset of the whole project's
mission.
  * A mailing list -- possibly.
  * A web site [within the main Debian site] -- possibly.
  * A repository for code or files -- possibly.
  * Other things depending on the project.

Custom Debian Distribution
  * A Debian Subproject.
  * The goal is to create a variant of Debian for a specific
purpose, but utilizing the Debian development framework and
resources, and feeding back* the work into the super-project.

(* Perhaps this is slightly misleading. A major portion of the
work will of course be done within the super-project itself.
Some things, however, will first see its light as a solution for
a specific Custom Debian Distribution. The goal then is to make
the solution general enough for use in the super-project, if
this is at all sensible. It's an evolutionary process.)

Flavor
  * A set of predefined choices applied to a Custom Debian
Distribution, making different flavors of the same Custom Debian
Distribution slightly different in some respects.
  * A way to differentiate different parts of a distributed system
that logically belong to the same Custom Debian Distribution --
several installations that cooperate to create a larger whole.
  * A set of install-time choices and actions that alter the
installation procedure.
  * A set of packages that are automatically installed and
configured, possibly with some variables set by a user.

By looking at this, I see lots of open questions and tasks that need to
be carried out for all three areas.

For subprojects, there needs to be a way to determine if something is an
official Debian subproject. I think being listed on what is currently
http://www.debian.org/devel/, under the heading "Projects", would be the
indication of this. The rest is work on the Subproject HOWTO and
possible further discussions that are best deferred until the work has
started and the issues come up.

For Custom Debian Distributions, little needs to be done. This indicates
the term is successful and clear. The Subproject HOWTO should include
something like the above definition. Perhaps more detailed, but ok.

For flavors, there is heaps of work to be done. In another thread,
Andres Salomon said, among other things along the same line:

"...should be concentrating on the framework that will make flavors
possible. There is much that remains to be done on the technical
level..."
(http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg00393.html)

I see flavors manifesting themselves technically in two places:
  * In the installation procedure of Custom Debian Distributions,
probably as hooks and/or udebs for debian-installer.
  * In the package pool, as packages which are built general enough
to support pre/postinst configuration by the above method, and
as both new and special versions of certain packages.
  * As tasks and metapackages. Tasks could be hierarchial to support
the structure discussed in this thread.

One final semantic thing about flavors that I would like to propose: the
"plain" flavor.

Re: OT: Smartcards and Physical Security

[Tom]

On Thu, Dec 04, 2003 at 11:43:21AM -0600, Manoj Srivastava wrote:

>   Snippy, aren't we? Usually it is better to have basic logic
>  straight before you try for a mistaken sense of haughtiness. 

My logic is correct; apparently my understanding of the goals of the 
Debian project is not.  I always thought it was first and foremost for 
the devs themselves ("we don't care if anybody uses it but us").  Under 
that reasoning, I'd think you'd *want* to spend money to have the best 
for yourselves.  The second and lesser reason is as a benefit for 
society -- thus the comparision to the orgs you say are not like Debian 
at all.

But primarily I would have thought you'd really want to have the best 
environment in the world.  I'm not saying you don't want that, I just 
didn't realize $30 would be a showstopper, especially since as you say 
you are already contributing so much.

But that's just me.

> 
>   Let me see if I can point out the logical flaws in words with
>  few syllables.

Um, yeah.  Take a bath.

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

[Tom]

On Thu, Dec 04, 2003 at 02:23:54PM -0500, Matt Zimmerman wrote:
> On Tue, Dec 02, 2003 at 05:19:22PM -0800, Tom wrote:

> You must be joking.  If the developer's system is compromised, and he logs
> into another system after that time, that system can be easily compromised
> also.

Yes, but the reason it would have been efficiacious in this *particular* 
instance is the hacker sniffed the password, and then logged on to 
Debian's servers later at his leisure from a different PC.  With a 
smartcard, he would have had to done it *on* the Dev's infected PC 
*while* the smartcard was plugged in.  In theory the smartcard would not 
be plugged in all the time, thus diminishing the attack surface.

Re: Bits from the RM

[Peter S Galbraith]

> On Dec 4, 2003, at 10:56, Peter S Galbraith wrote:
> 
> > But another package's was using convert
> > in the build stage to convert some images and it was failing.  The bug
> > was elevated to release-critical.  I don't think it would be fair to
> > remove imagemagick from the distribution for such a case.
> 
> More importantly, it'd be quite counterproductive to remove it. But
> having a RC bug does not mean the RM will remove it; indeed, he may even
> chose to 'sarge-ignore' the bug.

Well, earlier in the thread people were talking about a scenario in
which packages with RC bugs would automatically get removed.  I was just
pointing out that it wouldn't be fair to elevate a non-RC bug to RC
simply because _another_ package uses that bit (and could probably work
around it anyway).

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Zenaan Harkness]

On Fri, 2003-12-05 at 05:49, Felipe Almeida Lessa wrote:
> > On Thursday 04 December 2003 13:19, Andrew Suffield wrote:
> > The other question is "how hard could it be to adapt menu to desktop files 
> > ?".
> I think only one thing is blocking the whole idea of moving from Debian Menu 
> style to freedesktop.org style: the work that need to be done. In other 
> words, people don't wanna use the .desktop format because the have already 
> write a debian/menu.

This is my impression from the threads too.

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: apt-rpm article -- the features we don't have

[Matt Zimmerman]

Just making another pass over this to associate the bug numbers for those
who are interested (especially in helping with the merge effort).

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

> To install a package directly, with apt downloading any necessary
> dependencies:
>   apt-get install rpmver-2.0-13498cl.i386.rpm

#47379

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

#47437 doesn't mention build-dependencies, but the implementation would be
similar, so I don't think it justifies a separate bug.

> Next is a bit about local repositories that work w/o a Packages file.
> Instead of needing to keep the Packages file up-to-date, apt just scans
> the rpm files in the local repository directory. Of course this needs a
> file:// repository. Sounds just a smidgen easier than using
> mini-dinstall.

This is interesting; probably deserves a new wishlist bug.

> There is something vague about improvements in the "upgrading
> algorythm" that may or may not apply to us.

I think these parts are classified in #207400.

> There is a bit about an apt shell which sounds mildly interesting.

Michael Vogt filed a patch as #71.

-- 
 - mdz

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Billy Biggs]

Felipe Almeida Lessa ([EMAIL PROTECTED]):

> It would be *very* hard to make the developers agree, but we need to
> think in the Open Source Community as a whole. The Debian Menu is used
> only by Debian, but the .desktop is or may be used by any
> distribution. 
> 
> Now just imagine what would happen if all the major distributions used
> a standard created by them. We would see Debian Menu, RedHat Menu,
> Mandrake Menu, SuSE Menu, everything in just one upstream package?

  This is already happening.  Mandrake uses the Debian menu system
format, but with different category names.  ALT Linux is another
RPM-based distribution that uses Mandrake-style Debian menus.  This is a
pain for packaging as I describe in a recent freshmeat editorial [1].

  Some problems I would hilight:

  1. Multiple menu systems hurt my documentation, since I have no way of
 indicating to a user where to find my program or what it is called
 in the menu (and I have had bug reports about this).
  2. Distribution-specific menu systems are an additional support cost
 for packaging on that distribution.

  Some advantages I would hilight of the .desktop menu entries:

  1. desktop-file-utils [2] is a nice set of tools for manipulating
 .desktop files, so distributions can provide policy for category
 names in a clean manner without affecting additional metadata.
  2. The menu-spec draft [3] provides a clear method for applications on
 where to install their menu entries.

  I believe that adopting the freedesktop.org standard in Debian would
be very useful for application developers trying to support their
application across multiple distributions, and to developers wanting to
depend on a flexible base for new uses of the menu.  Furthermore, it
would help to show Debian's interest in supporting standardization
efforts.

  -Billy

  [1]  http://freshmeat.net/articles/view/992/
  [2]  http://freedesktop.org/Software/desktop-file-utils
  [3]  http://freedesktop.org/Standards/menu-spec

Re: Revival of the signed debs discussion

[Daniel Jacobowitz]

On Thu, Dec 04, 2003 at 02:41:43PM -0500, Matt Zimmerman wrote:
> On Thu, Dec 04, 2003 at 12:28:41PM -0600, Manoj Srivastava wrote:
> 
> > On Thu, 4 Dec 2003 11:47:50 -0500, Matt Zimmerman <[EMAIL PROTECTED]> said: 
> > 
> > > What kind of real world attacks do signed debs prevent?  Not a
> > > compromised buildd, or a compromised maintainer's workstation.
> > 
> > It would allow me to copy .debs around with other people, or
> >  use .debs not made available through the usual chain of security; as
> >  long as the author hapens to be in my web of trust.
> 
> What kind of real world attacks do signed debs prevent?
> 
> The only one which comes to mind is a rogue Debian developer that you do not
> wish to trust, even though the project trusts him.

Someone pretending to be someone Manoj trusts, offering him a corrupted
.deb offline?

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Nathanael Nerode]

Andrew Suffield wrote:
>That wasn't his argument. However, it's similar, and the response is
>the same: why not simply add these features to the Debian menu system?

Why be gratuitously different?

There's now a standard used by KDE and GNOME which has more features than the 
Debian menu system.

Which makes more sense:

* Investing time in adding features to the Debian menu system, keeping maximum 
menu work on the Debian maintainers, retaining poor GNOME and KDE 
integration, and generally competing with the freedesktop standard

* Adopting the freedesktop standard and absorbing its benefits for GNOME and 
KDE users immediately, while benefiting from upstream work

Frankly, I'm not clear why there's opposition to adopting the freedesktop 
draft specifications in Debian.

Are there any technical complaints about it?  (Apart from "I don't like 
the .desktop extension", which I consider unimportant.)

Is it that it's still a "draft" specification?
Or is it simply that the freedesktop standard currently only works in KDE and 
GNOME 2?

Perhaps a "backward-compatability-menu" module could be written to 
automagically generate Debian menu entries from .desktop entries.  If this 
would satisfy everyone's complaints, I'll write the damn thing.

--Nathanael

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Tore Anderson]

* Marc Haber

 > Splitting up the config file in small files was necessary to do
 > debconf support, which is a Debian requirement.

  Debconf support is now required?  I'm flabbergasted.  Could you
 please point me to this section of our policy?  I certainly cannot
 find it.

* Tore Anderson

 >- A exim4-base package containing the default debconf scripts,
 >  which installs a (monolithic) configuration file.

* Marc Haber

 > Please state how you intend to fulfill policy with that approach. Give
 > code examples.

  An existing code example from the top of my head would be the current
 xserver-xfree86 package's config and postinst scripts.  Another package
 which does much of the same thing, albeit in quite a different manner,
 is proftpd.  I'm sure there's many more.

  Would you and Andreas seriously consider modifying the Exim packages
 to the layout I suggested in my former post?  If so, I would be happy
 to spend some time developing a patch for this purpose.

-- 
Tore Anderson

Re: Revival of the signed debs discussion

[Matt Zimmerman]

On Thu, Dec 04, 2003 at 03:58:38PM -0500, Daniel Jacobowitz wrote:

> On Thu, Dec 04, 2003 at 02:41:43PM -0500, Matt Zimmerman wrote:
> > What kind of real world attacks do signed debs prevent?
> > 
> > The only one which comes to mind is a rogue Debian developer that you do
> > not wish to trust, even though the project trusts him.
> 
> Someone pretending to be someone Manoj trusts, offering him a corrupted
> .deb offline?

s/offline/without the corresponding signed metadata/

The advantage would certainly appear to be one of convenience (keeping
everything in one file), rather than security (preventing attacks).

-- 
 - mdz

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Joey Hess]

Tore Anderson wrote:
>  > Splitting up the config file in small files was necessary to do
>  > debconf support, which is a Debian requirement.
> 
>   Debconf support is now required?  I'm flabbergasted.

debconf support is a requirement if you want to be supported
(reconfigured) by base-config, which is a requirement for our default
MTA.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Steve Greenland]

On 04-Dec-03, 09:26 (CST), Jonathan Dowland <[EMAIL PROTECTED]> wrote: 
> It has been bashed around a lot but I think the menu system needs to be
> discussed thoroughly, as everyone seems to have reserved opinions on how
> it should be developed. 

No it doesn't need to be discussed thorougly, it has already been beaten
to death several times.

What needs to happen is to either add the missing functionality to the
existing Debian menu file format and tools, so that it can generate
complete .desktop files for those desktop environments that can use
them, OR, enhance the existing tools (e.g. menu-methods) to generate the
appropriate window manager specific menu files from the .desktop format
for the many Debian supported window managers (or desktop environments)
that don't support them.

In either case, you need to work with the menu package maintainer, who
is, IIRC, already working on this, and probably does not need a bunch
more discussion by people who aren't going to do the work.

As for me, I'm happy to provide either my current menu files, which are
supported by all of the DE/WM systems in Debian, *or* .desktop files,
*when* they are supported by all (or at least most) the DE/WM systems in
Debian.

Steve
-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Andrew Suffield]

On Thu, Dec 04, 2003 at 03:44:56PM -0500, Nathanael Nerode wrote:
> Andrew Suffield wrote:
> >That wasn't his argument. However, it's similar, and the response is
> >the same: why not simply add these features to the Debian menu system?
> 
> Why be gratuitously different?

Why not? Why waste effort just to be the same as everybody else?

It's identical to the old rpm vs. deb argument.

> There's now a standard used by KDE and GNOME which has more features than the 
> Debian menu system.
> 
> Which makes more sense:
> 
> * Investing time in adding features to the Debian menu system, keeping 
> maximum 
> menu work on the Debian maintainers, retaining poor GNOME and KDE 
> integration, and generally competing with the freedesktop standard
> 
> * Adopting the freedesktop standard and absorbing its benefits for GNOME and 
> KDE users immediately, while benefiting from upstream work

This is the fallacy of the false dilemma.

> Frankly, I'm not clear why there's opposition to adopting the freedesktop 
> draft specifications in Debian.
> 
> Are there any technical complaints about it?  (Apart from "I don't like 
> the .desktop extension", which I consider unimportant.)

It doesn't support anything but gnome or kde. We have a system that
works for everything, and it is unlikely that anybody else will go to
that much trouble.

> Perhaps a "backward-compatability-menu" module could be written to 
> automagically generate Debian menu entries from .desktop entries.  If this 
> would satisfy everyone's complaints, I'll write the damn thing.

That's half of what is needed (to support gnome and kde within the
debian menu system). The other half is the reverse conversion - take
the upstream .desktop file, and convert it to a debian manu
entry. That supports everything other than gnome and kde. It should be
pretty easy - they're simple text files.

Adding the extra features that .desktop files have should also be
pretty easy, if not trivial. They aren't exactly sophisticated - just
some more string fields to pass through.

None of that should be more than an afternoon's work, all
together. Converting debian over to use .desktop files exclusively
would be significantly more work for no real gain.

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


signature.asc
Description: Digital signature

Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Steve Greenland]

On 04-Dec-03, 14:44 (CST), Nathanael Nerode <[EMAIL PROTECTED]> wrote: 
> There's now a standard used by KDE and GNOME which has more features than the 
> Debian menu system.

And missing one key one: working with menu sysems other than KDE and GNOME.

> Which makes more sense:
> * Investing time in adding features to the Debian menu system, keeping
> maximum menu work on the Debian maintainers, retaining poor GNOME and
> KDE integration, and generally competing with the freedesktop standard

...but which support the hundreds (thousands?) of menu entries that
already exist in Debian packages.

> Perhaps a "backward-compatability-menu" module could be written to 
> automagically generate Debian menu entries from .desktop entries.  If this 
> would satisfy everyone's complaints, I'll write the damn thing.

Do it. Get it added to the menu package, in such a way that it
automatically creates/updates/removes the appropriate /usr/lib/menu/
entries when a package is installed/upgraded/removed. Then the existing
menu methods for all the other WMs would continue to work.

Most of us (I think) don't object to using the .desktop format. We
object to having *both*.

Steve


-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: Revival of the signed debs discussion

[Matt Zimmerman]

On Wed, Dec 03, 2003 at 08:07:53AM +0100, Goswin von Brederlow wrote:

> I wrote a little script that checks what apt things its installing
> against what the control files of the debs say. I will test it with
> some more fakes and then file it in the BTS.

Why would you do this with a script rather than in apt directly?

-- 
 - mdz

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Tore Anderson]

* Marc Haber

 > Splitting up the config file in small files was necessary to do
 > debconf support, which is a Debian requirement.

* Tore Anderson
 
 >   Debconf support is now required?  I'm flabbergasted.

* Joey Hess

 > debconf support is a requirement if you want to be supported
 > (reconfigured) by base-config, which is a requirement for our default
 > MTA.

  Quite.  However, as far as I know, base-config does not require the
 resulting configuration to be lots of tiny files as opposed to a single
 file, nor does it require the configuration to be split into a package
 of its own.  Policy does not require any of this either.

  These two issues are my main griefs with the Exim packages.  The
 existing debconf scripts are just fine;  I certainly do not wish to see
 them replaced with something akin to the old eximconfig script.

-- 
Tore Anderson

New 2.4 kernels in unstable when archive reopens?

[Nathanael Nerode]

It's clear that it's important to fix the brk vulnerability.

It is intended to release sarge with a 2.4 kernel as the default, I believe.

Therefore, it is imperative that there be a 2.4 kernel in sarge which has
the brk vulnerability patched.

Currently, none of the 2.4 kernels in sarge or sid have it fixed, apparently.

Could one of the Debian kernel maintainers please confirm that there
are plans to have either 2.4.23, or a patched version of 2.4.22, available
in sid as soon as possible?  Or, if there aren't such plans

-- 
Nathanael Nerode  
http://home.twcny.rr.com/nerode/neroden/fdl.html

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Billy Biggs]

Steve Greenland ([EMAIL PROTECTED]):

> On 04-Dec-03, 14:44 (CST), Nathanael Nerode <[EMAIL PROTECTED]> wrote: 
> > There's now a standard used by KDE and GNOME which has more features
> > than the Debian menu system.
> 
> And missing one key one: working with menu sysems other than KDE and
> GNOME.

  So far there has been a lot of support for the .desktop standard
effort.  Which systems do you refer to that are not supporting,
adopting, or intending to adopt the .desktop standard?

  -Billy

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

[Matt Zimmerman]

On Thu, Dec 04, 2003 at 11:55:26AM -0800, Tom wrote:

> Yes, but the reason it would have been efficiacious in this *particular*
> instance is the hacker sniffed the password, and then logged on to
> Debian's servers later at his leisure from a different PC.  With a
> smartcard, he would have had to done it *on* the Dev's infected PC *while*
> the smartcard was plugged in.  In theory the smartcard would not be
> plugged in all the time, thus diminishing the attack surface.

Not really; he just has to set things up ahead of time.  This is like
claiming the attacker has to be present in order to sniff your password from
a telnet session (he doesn't; he just has to have been around at any time
before then in order to set up a sniffer).

-- 
 - mdz

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

[Tom]

On Thu, Dec 04, 2003 at 06:13:49PM -0500, Matt Zimmerman wrote:
> 
> Not really; he just has to set things up ahead of time.  This is like
> claiming the attacker has to be present in order to sniff your password from
> a telnet session (he doesn't; he just has to have been around at any time
> before then in order to set up a sniffer).

That's totally true.  It's not the way this attack happened though.
All I know is it's a layer and experts say layered defense is best.
I still think it would discourage the cracker.  A lot of the "open a 
netcat over the exposed pipe" tricks wouldn't work iff the smartcard 
auth stack wasn't compromised -- the netcat couldn't get auth'd, and the 
server wouldn't buy it.  The problem now is a pipe is a pipe.

Just rambling... I'm sure there's tons of holes in what I just said.

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Billy Biggs]

Andrew Suffield ([EMAIL PROTECTED]):

> > Are there any technical complaints about it?  (Apart from "I don't
> > like the .desktop extension", which I consider unimportant.)
> 
> It doesn't support anything but gnome or kde. We have a system that
> works for everything, and it is unlikely that anybody else will go to
> that much trouble.

  Can you back this up?  The desktop and menu standards seem to have a
lot of support in the window manager developer community.  Furthermore,
it would be pretty trivial to convert the Debian system over to .desktop
files (even more trivial than the other way around).

  -Billy

Building a distribution from source?

[Steve Kemp]

  I wasn't going to post this, but it might be relevent to the
 ongoing custom distribution stuff that's happening.
  
  I've been experimenting with producing a hardened Debian derivitive
 as a small piece of paid work.  This mostly means compiling things with
 a stackguard compiler, using format guard, and enforcing policies, etc.

  (We know that stackguard isn't going to produce a completely 
 hardened environment; as all the return-into-libc type exploits will
 work.  Lets not discuss/flame about that.  Pretty please!)

  All of that part I'm happy with.  I have a modified glibc and compiler
 and am confident that I can recompile all the base packages and others that
 are necessary.  It's the process of installing after that after that I'm 
 a bit confused.

  If I wish to produce an installation CD-ROM identical to that used
 in woody, with my packages installed how do I do that?  Is there some
 tool that will allow me to create an ISO with my packages.

  I'm wondering if jigado, or using debootstrap from my apt repository
 should be the way to go?  Any pointers appreciated.

  The other approach which is simpler to manage but harder to install
 is to insist upon a stable installation, then have an apt repository
 with each package I've recompiled have a higher version number, or
 in a distribution of my own with a release file.  (eg like testing,
 but "steving" or similar.)

  The latter approach appears to be what Adamantix are doing.

Steve
--
Still Looking for work
Can make coffee well !


pgpoHrWJUjvqk.pgp
Description: PGP signature

Re: New 2.4 kernels in unstable when archive reopens?

[Shaya Potter]

http://www1.cs.columbia.edu/~spotter/debian/kernel/

those are Herbert's packages, archive isn't processing yet, so can get
them from the above link.

On Thu, 2003-12-04 at 17:49, Nathanael Nerode wrote:
> It's clear that it's important to fix the brk vulnerability.
> 
> It is intended to release sarge with a 2.4 kernel as the default, I believe.
> 
> Therefore, it is imperative that there be a 2.4 kernel in sarge which has
> the brk vulnerability patched.
> 
> Currently, none of the 2.4 kernels in sarge or sid have it fixed, apparently.
> 
> Could one of the Debian kernel maintainers please confirm that there
> are plans to have either 2.4.23, or a patched version of 2.4.22, available
> in sid as soon as possible?  Or, if there aren't such plans
> 
> -- 
> Nathanael Nerode  
> http://home.twcny.rr.com/nerode/neroden/fdl.html
> 

Re: Building a distribution from source?

[Russell Coker]

On Fri, 5 Dec 2003 10:39, Steve Kemp <[EMAIL PROTECTED]> wrote:
>   I've been experimenting with producing a hardened Debian derivitive
>  as a small piece of paid work.  This mostly means compiling things with
>  a stackguard compiler, using format guard, and enforcing policies, etc.

Are you using any extra patches to GCC?  Or just a GCC built with the 
propolice option?

How difficult is it to bootstrap this?  Can you compile glibc with these 
options without affecting anything else?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page