Unsere Reisen 2004.

Sehr geehrte Damen und Herren.
Sie finden in unsere Webseit-www.smyrnagroup.net unsere Rundreisen als 
Sonderangebote ,die wir als
Studienreisen-Bildungsreisen und Christliche Reisen durchführen.
In unserer Webseite www.smyrnagroup.net können  sie auch unsere andere Reisen 
für 2004 finden.
Wie ;
***Eine Woche Istanbul Euro 540 Flug+Hotel-HP+Ausflüge aus 
Deutschland-Schweiz-Oesterreich.
***Eine Woche Tuerkische Riveria Euro 540 Flug+Hotel-HP+Ausflüge aus
Deutschland-Schweiz-Oesterreich .
***Bade-Urlaub Hotels der Tuerkei mit Preisen .(Auch Fünf Smyrna Group Hotels)
***Rundreisen-Studienreisen-Christliche Freizeiten, 
***Jugend Reisen und Hotels.
***Behinderten Reisen. Strand Hotels für Behinderten.
***Senioeren Reisen und Gesundheits Reisen mit Thermal Hotels.
***Sport Reisen Golf wie Trainingslagern für Tennis-Fussball und Schwimmen, 
***Blaue Reisen mit Smyrna Schiffe.
Wenn sie die Tuerkei Flüge direkt buchen möchten,melden sie bitte bei uns .
Wir stehen für ihre Fragen zur Verfügung.
Mit Herzlichen Grüssen.

Ihr Dr.Sedat Igdeci

[EMAIL PROTECTED]

Re: Backporting 2.4.23 kernel packages

[Russell Coker]

On Fri, 5 Dec 2003 16:41, Andrew Pollock <[EMAIL PROTECTED]> wrote:
> So, I was wondering how to go about taking the source package for
> 2.4.23-686 (and the SMP version) and backport them to stable?

Why not just use a machine running unstable to do the compile?

I use unstable machines to compile all my kernels, they install and run fine 
on woody systems.

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

[Cameron Patrick]

On Fri, Dec 05, 2003 at 02:36:37AM +, Andrew Suffield wrote:

| Right, that's what I just described (later on). The thread had
| previously been about people wanting to throw away the Debian menu
| system and replace it with the .desktop one, or worse, have both
| coexist.

If we can convert menu entries between the two formats and do so in a
sane manner, having the two coexist shouldn't be a problem, and could
potentially be the first step towards standardising on freedesktop's
format.  I agree, though, that having the two coexist with completely
different menu items on each is a bad position to be in - and sadly,
that's pretty much what we've got now :(

I just had a look at the menus of both KDE and Gnome, and it seems that
even though the .desktop file format is supposedly common to both, they
have different menus with, for the most part, non-intersecting sets of
programs on each.  Aaargh!  This is bad, and I think it needs to be
fixed if we are to attempt to do too much more with .desktop files.

| Yeah, inverted the sense, you get the idea. We need both tools, at
| which point there's no longer a reason not to just continue using the
| existing Debian menu system.

Except that AFAIK .desktops are still semantically richer than the
existing Debian system, and have more momentum behind them outside of
Debian.  Upstream packages are much more likely to ship to .desktop
files than they are Debian menu entries.  Admittedly I'm not convinced
that they're ready enough in other ways to replace what we have now.

| > In fact, it looks like it's been implemented twice, once for KDE and
| > once for GNOME.  (Is there any reason why the .desktop files aren't being
| > shared between the two DE's?  It also appears to me that KDE is doing a
| > marginally better job of integrating the Debian menu into the KDE menu.)
| 
| Yup, that. It needs de-stupiding, which basically means rewriting,
| given the triviality of this particular part.

Agreed.

In my opinion, the current Debian menu hierarchy is a nightmare from a
usability perspective.  There is a freedesktop.org menu spec[1] that
builds upon .desktop entries and sounds to me as though is should help
some of these problems, by having .desktop files assigned to multiple
categories and attempting to generate a menu hierarchy from those.  It
also supports merging menus from multiple sources, which might make it
easier to incorporate Debian menu entries into it.  However, I don't
believe it's actually been implemented by anyone yet, and I'm not making
any claims about how useful it might be practice.

Cheers,

Cameron.

[1] http://freedesktop.org/Standards/menu-spec/menu-spec-0.8.html -
mentioned on the debian-usability list months ago.

Re: Backporting 2.4.23 kernel packages

[Andrew Pollock]

On Fri, Dec 05, 2003 at 05:59:40PM +1100, Russell Coker wrote:
> On Fri, 5 Dec 2003 16:41, Andrew Pollock <[EMAIL PROTECTED]> wrote:
> > So, I was wondering how to go about taking the source package for
> > 2.4.23-686 (and the SMP version) and backport them to stable?
> 
> Why not just use a machine running unstable to do the compile?
> 
> I use unstable machines to compile all my kernels, they install and run fine 
> on woody systems.

I presume I can lower the dependencies on things like modutils and whatnot
down to the versions that are in stable with no ill-effects?

Andrew

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

[cobaco]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2003-12-04 10:41, Andreas Tille wrote:
> 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? ;-) )

hm, here are the names I can remember:

Petter , me, (Kurt Gramlich, Maximillian Wilhelm, Frank Matthieß -> not on 
devel as far as I know) from Skolelinux

Mako, Enrico who organized the meeting

David Martinez (I think), and one or two others from Meta-distros.

about half a dozen others whose names I don't recall

> > 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.

For Skolelinux there's a contact page with the names of the coordinators for 
the different languages (14 now :) at http://i18n.skolelinux.no/kontakt.html

> 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.

i'll have a look at this this weekend
- --
Cheers, cobaco

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

iD8DBQE/z6i35ihPJ4ZiSrsRAgR2AJwLv+3hbjlPA9ZpZbG3yEWCLraS8wCfWf3i
yDZRe5YwIZ6cmv8YSowx7CQ=
=B0wj
-END PGP SIGNATURE-

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

[cobaco]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2003-12-03 21:58, Andreas Tille wrote:
> On Wed, 3 Dec 2003, cobaco wrote:
> > hm, I've added a definition to the wiki:
> >
> >   A Custom Debian Distribution (CDD) is a version of Debian that is
> > tailored
>
> I do not like the term "version".  I'd prefer a "subset of Debian".  You
> get a CDD together with main but you get a helping hand to cope with the
> sheer mass.


> >   for a particular situation/target group out-of-the-box.
> >
> >   Any changes necessary to Debian to support this particular
> > situation/target group arge merged back into Debian whenever possible,
> > improving Debian as a whole.
>
> There are no changes to Debian, because CDDs reside completely in
> main / testing /unstable as any other package.

_ideally_ there are no changes. In practice there will be. For instance:
In skolelinux there's currently a package called locale-config-skolelinux
which sets up de default locale for all users. This package is not part of
Debian. Instead there's some discussion with the relevant maintainer about
merging locale-config-skolelinux, language-env,  and the different
user-language packages, with the hope of eventually creating one package to
set the default locale for both single users and the system as a whole.

- -> while being a subset is the goal we have in mind, it's not always the
actual situation. This is a consequence of
1. inertia in Debian, because of which getting things changed takes a while
2. the fact that some experimentation is often necessary to find the right
solution, leading to non-optimal solutions that "get the job done" being
used by the CDD in the meanwhile.
- --
Cheers, cobaco

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

iD8DBQE/z5KN5ihPJ4ZiSrsRApHoAJ9zpIKoi7nRsig7Wv4GWB4NU7kK2ACeNKiG
1vaDdxRaS0AAj5ZRKDym1qw=
=HqT0
-END PGP SIGNATURE-

Re: debian pxe dhcp netinstall (debconf enterprise fai etc.)

[Chad Walstrom]

On Thu, Dec 04, 2003 at 05:37:49PM -0800, Mark Ferlatte wrote:
> I did what you are trying to do using systemimager, cvs, and cvsup.
> ...  There are a few rough spots (mostly in that I don't have a fully
> automatic way to restart daemons that have been updated in the golden
> client, so I have to restart them by hand), but in general it works
> very well, and has saved me a lot of time.

This is all very well and find if you're using a single architecture
with nearly identical hardware setups.  Granted, with discover and
read-edid, things are a little easier.

When you need extreme customizability in installs, FAI does a very good
job.  It "feels" like a kludge at times, but once you wrap your head
around the process, it's actually pretty easy to follow.  For your
debconf database, you could always create a quick script to copy over an
existing database.  Or you could possibly look into hacking on the LDAP
backend for debconf.

I was intrigued by Progeny's autoinstall Python script, but never had a
chance to look into it further.

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


pgpbbRdXTbW5y.pgp
Description: PGP signature

Re: recovery status update

[Christian Kurz]

Hi James,

first let me thank you for your good work so far on the recovery of the
debian machines. I just wanted to add one note:

On [05/12/03  1:51], James Troup wrote:
> Use the anonymous upload queue on ftp-master.  I believe you want to
> use something like "dupload --to anonymous-ftp-master foo.changes" for
> dupload and "dput ftp-master foo.changes" for, err, dput.  But I don't
> use either of these programs and haven't tested that.

The default configuration of dput was changed in the past to use the
anonymous upload-queues. Only if people really want to use scp/rsync
(like I do when testing new releases), it's necessary to specify the
host. Otherwise it's enough if people use "dput foo.changes", if they
haven't modified the default configuration (except for username. ;-)

Christian
-- 
   Debian Developer (http://www.debian.org)
1024D/B7CEC7E8 44BD 1F9E A997 3BE2 A44F  96A4 1C98 EEF3 B7CE C7E8


pgpU4h5ObJ9DG.pgp
Description: PGP signature

Re: debian pxe dhcp netinstall (debconf enterprise fai etc.)

[Mark Ferlatte]

Chad Walstrom said on Fri, Dec 05, 2003 at 02:17:55AM -0600:
> > I did what you are trying to do using systemimager, cvs, and cvsup.
> > ...  There are a few rough spots (mostly in that I don't have a fully
> > automatic way to restart daemons that have been updated in the golden
> > client, so I have to restart them by hand), but in general it works
> > very well, and has saved me a lot of time.
> 
> This is all very well and find if you're using a single architecture
> with nearly identical hardware setups.  Granted, with discover and
> read-edid, things are a little easier.
 
I am using all x86, but I've got very different hardware setups; 4 different
types of RAID, many 1U boxen with different ethernet cards that are not RAID,
some SMP some not, some SCSI, some IDE, etc.

Pretty much all of the non-autodetectable hardware configuration is restricted
to three places: the kernel, /etc/fstab, and lilo.conf/grub.  (Okay, 4 places
if you include the X server config).

I have an SMP and a non-SMP kernel installed in the golden image, and I have a
SCSI vs. non-SCSI initial setup (due to the different device filenames
requiring different setup commandlines and fstab), but other than that, there's
nothing special necessary.  The machines that are SMP have lilo configured to
start the SMP kernel instead of the UP one (since there's no autodetect for
that at boot time), but that's not a big deal.  The kernel's are just the
Debian default ones, which have most things built as modules; I just load the
disk driver modules that I know I need from the initrd (which means that I'm
wasting a little kernel memory, but I could unload the unused ones after boot;
I just don't).

FAI is good, but it doesn't handle updating the systems once you have them
installed.

M


pgpgvtr38XhjZ.pgp
Description: PGP signature

Re: Building a distribution from source?

[Javier Fernández-Sanguino Peña]

On Fri, Dec 05, 2003 at 01:45:37PM +1100, Russell Coker wrote:
> On Fri, 5 Dec 2003 13:18, Steve Kemp <[EMAIL PROTECTED]> wrote:
> > On Fri, Dec 05, 2003 at 12:10:44PM +1100, Russell Coker wrote:
> > > Are you using any extra patches to GCC?  Or just a GCC built with the
> > > propolice option?
> >
> >   Yes I am using slightly modified patches from http://www.immunix.org/.
> >
> >   The propolice is something that I shall be evaluating next.
> 
> I believe that our GCC packages already have propolice patched in but not 
> enabled.  Therefore it should be a much easier change to make for it to be 
> included.

This is true, debian/patches has a line for propolice (currently commented 
out)

> 
> As propolice is not invoked unless a special command-line parameter is passed 
> to GCC it seems like a harmless thing to include.  Why aren't GCC packages 
> being built with it?

Daniel Jacobowitz says (in #213994)

"They're large patches, with no testing on most architectures.  They
touch platform independent code.  If it really did do nothing without
the option, and we were convinced of that, then maybe they could be
applied - I'm not convinced."

The bug is tagged upstream so it seems that gcc maintainers will not enable 
this until upstream adds it into the mainstream source.

Regards

Javi

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

[Andreas Metzler]

Billy Biggs <[EMAIL PROTECTED]> wrote:
> 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?

Have you any evidence that (or any idea whether) fvwm, icewm, wmaker,
lwm, ...[1] plan to support .desktop?
   cu andreas
[1] Insert any of 'grep-available -FProvides  -s Package window-manager'
with menu-support here.

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

[Andreas Metzler]

Tore Anderson <[EMAIL PROTECTED]> wrote:
> * 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.
[...]

No. All they have to do is to install their configuration as
/etc/exim4/exim4.conf.
   cu andreas

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

[Andreas Tille]

On Thu, 4 Dec 2003, cobaco wrote:

> > There are no changes to Debian, because CDDs reside completely in
> > main / testing /unstable as any other package.
>
> _ideally_ there are no changes. In practice there will be. For instance:
> In skolelinux there's currently a package called locale-config-skolelinux
> which sets up de default locale for all users. This package is not part of
> Debian. Instead there's some discussion with the relevant maintainer about
> merging locale-config-skolelinux, language-env,  and the different
> user-language packages, with the hope of eventually creating one package to
> set the default locale for both single users and the system as a whole.
Well, at least for my understanding SkoleLinux is not a "Custom Debian 
Distribution"
exactly because they have packages which are not integrated in Debian.  This is
no problem at all, but exactly here is the cruxial point of our definition.
In my talk about CDD in Oslo I suggested the SkoleLinux people to take over
the Debian-Edu ball because Raphael Herzog announced that he was running out
of time.  Debian-Edu *is* a CDD because it is completely inside Debian and
the suggestion is that SkoleLinux people patch the packages according to their
needs.  The *product* (one bootable CD) which contains Debian-Edu plus some
extra packages which are necessary for whatever reason might be called
SkoleLinux but this is not a CDD per the definition I was using in my talk
in Oslo.  There was nobody who disagreed ...

> -> while being a subset is the goal we have in mind, it's not always the
> actual situation. This is a consequence of
> 1. inertia in Debian, because of which getting things changed takes a while
> 2. the fact that some experimentation is often necessary to find the right
> solution, leading to non-optimal solutions that "get the job done" being
> used by the CDD in the meanwhile.
Obviousely we use a different definition of CDD and this is causing the
trouble.  If we should agree to your definition of CDD we have to come back
for a common name for Debian-Jr, Debian-Med, Debian-Edu, Debian-Np, ...

Kind regards

Andreas.

-- 
Sie schaffen eine Wüste und nennen es Frieden.
-- Publius Cornelius Tacitus (55-120)

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

[Andreas Metzler]

Tore Anderson <[EMAIL PROTECTED]> wrote:
> * 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.
[...]

3.10.1. No it is not "required" but "Prompting the user by other means,
such as by hand[7], is now deprecated." The alternative is shipping
a dpkg-conffile /etc/exim4/exim4.conf that _only_ does local delivery
(That is the only safe default.) and tell people to use $editor.

[...]
> > 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.

No, I am sorry (and thanks for the offer). You effectively proposed
repacking from scratch, which requires amounts of work and testing I
am not willing to invest. - I would need to hand the package over to
you.

If you think conf.d sucks like hell (where did I get this idea from? ;-)
try providing a patch for exim4-config-sane, which supports:
* debconf
* propagating changes in our exim4.conf (e.g. changed options for a
  transport) to the user on upgrade. I.e. dpkg-like conffile
  managment. That is the part where exim(v3) failed.
* no additional maintainance work i.e. it would need to base its
  config on the conf.d snippets in CVS. If I fix the AUTH
  examples in conf.d I don't want to duplicate the work. i.e.

An implementation would generate exim4.conf.example at build-time from
the conf.d snippets
  find conf.d/ -path '*/CVS/*' -prune -or -type f -print0 | \
 xargs -0 cat > exim4.conf.example.
and at installation would ask debconf-questions and generate a
exim4.conf from exim4.conf.example by filling in the anwers and use
ucf[1] to manage it.

As you can see I have rather well formed opinion on how the package
would need to work.

If exim4-config-sane worked well we could switch priorities and make _it_
important instead of of exim4-config.[3]

Pros and cons:
[ I'll explain in fup-message]

Don't start implementing yet, there is more to come.
  cu andreas

[1] or essentially a private copy or reimplentation of it.
[2] Or simply do without making separate packages, making conf.d
yes/no a medium debconf-question.
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Re: [custom] Debian Enterprise - packages

[Chris Halls]

On Wed, 2003-12-03 at 20:18, John Goerzen wrote:
> Debian Enterprise will have to support 64-bit platforms, which
> OpenOffice doesn't.

..yet.  That will be fixed by 2.0 at the latest.  Help is appreciated.

Chris

Re: Revival of the signed debs discussion

[Andreas Barth]

* Matt Zimmerman ([EMAIL PROTECTED]) [031204 22:25]:
> 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).

If it is more convenient, than security actions are far more often
made.


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: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[Andreas Tille]

On Thu, 4 Dec 2003, cobaco wrote:

> hm, here are the names I can remember:
>
> Petter , me, (Kurt Gramlich, Maximillian Wilhelm, Frank Matthieß -> not on
> devel as far as I know) from Skolelinux
>
> Mako, Enrico who organized the meeting
>
> David Martinez (I think), and one or two others from Meta-distros.
>
> about half a dozen others whose names I don't recall
I'm sorry that I was not able to enter this meeting because I was not
yet in Oslo.  Benjamin 'Mako' Hill and Enrico Zini told me about the meeting
and explained me the term in this way I presented in my talk.

> > > 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.
>
> For Skolelinux there's a contact page with the names of the coordinators for
> the different languages (14 now :) at http://i18n.skolelinux.no/kontakt.html
Please see my previous mail and try to accept that while absolutely incomplete
the common entry point for CDDs is:

http://www.debian.org/devel/

under the topic "Projects".  The reason for inventing the term CDD was not
to make more confusion by merging projects outside Debian in but to 
differentiate
user centric projects like Debian-Jr from for instance "The X Strike Force" or
"Debian IPv6 Project".  I'm very sorry that this is absolutely not reflected
in the page but you will find the relevant people caring for those projects
when following the relevant links.  Most of these CDDs have their own mailing 
list
but currently there is no common mailing list for all CDDs.  Instead we use
debian-devel by tagging the subject [custom].

[BTW, declaring that SkoleLinux as "no CDD" I absolutely do not respect their
 fine work.  I really love what they do and SkoleLinux is one of the most
 impressive derivatives of Debian, but it just does not (yet) fall under our
 definition.]

Kind regards

 Andreas.

-- 
Sie schaffen eine Wüste und nennen es Frieden.
-- Publius Cornelius Tacitus (55-120)

Re: debsums for maintainer scripts

[Manoj Srivastava]

On Thu, 04 Dec 2003 17:36:16 +0100, Thomas Viehmann <[EMAIL PROTECTED]> said: 

> 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.

What kind of accident? Files lost? We already have a list of
 files for files being deleted, and having hashes of the files helps
 not -- you need to download the deb to get them back Permissions
 changed or owner changed?  chesum hashes do not help there. How often
 have you had a mass corruption as an accident?  What exactly is the
 use case we are solving here?

manoj
-- 
And do you not think that each of you women is an Eve?  The judgment
of God upon your sex endures today; and with it invariably endures
your position of criminal at the bar of justice. Tertullian,
second-century Christian writer, misogynist
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 Thu, 4 Dec 2003 11:52:21 -0800, Tom  <[EMAIL PROTECTED]> said: 

> 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.

Methinks you know not yet the depths of the error: Goals of
 the Debian project?  Apart from the social contract, there is no such
 thing

> I always thought it was first and foremost for the devs themselves
> ("we don't care if anybody uses it but us").

For some, sure.

> Under that reasoning, I'd think you'd *want* to spend money to have
> the best for yourselves.

Money often does not buy as much security as you think (often
 it buys complacency).  A smart card shan't protect me from a person
 whose security habits I can't trust -- all a smart card tells me is
 that the card is the machine. There could be 50 people and two kegs
 of beer in close proximity.

Security is not gizmos. It is not cool hardware; it is people
 who follow secire processes. Blowing 40k collectively is unlikely to
 buy us much security.

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

> Um, yeah.  Take a bath.

Take a bath? take a _bath_? What are we, back in grade school now?

manoj
-- 
By definition, when you are investigating the unknown, you do not know
what you will find.
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

[Tom]

Let me start by saying I basically understand your last point: it's not 
worth it because it won't work.

On Fri, Dec 05, 2003 at 04:01:42AM -0600, Manoj Srivastava wrote:
>  who follow secire processes. Blowing 40k collectively is unlikely to
>  buy us much security.

Like I said, it may be that it would be wasted money.  But you are 
switcing arguments here.  Originally you were bristling at the 
suggestion that you spend your own money.  Now you seem to be okay with 
that, but saying it would be wasteful because you basically don't trust 
smartcards.

I don't trust them either, but they are a layer.  Of course, they may be 
an absolutely useless layer, but they may not.  I think this is your 
true objection (to smartcards at all) and not to the suggestion of 
having your spend your own money to improve the project.  And that's an 
acceptable belief (although it *may* not be correct).  But if you want 
to explore other, free ways to improve Debian's security process (such 
as auditing one another's machines or some other way I can't think of), 
that's a good thing.  The point is: a failure occured.  Don't let it 
happen again.

> 
> >> Let me see if I can point out the logical flaws in words with few
> >> syllables.
> 
>   Take a bath? take a _bath_? What are we, back in grade school now?

You're not seriously talking about taking pot shots are you?  Tit for 
tat.  But I withdraw the remark, I was thinking of the traditional image 
of the long-stringy-haired Unix hacker such as RMS.  I was picturing RMS 
-- I didn't mean anything else. :-)

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

[Manoj Srivastava]

On Thu, 4 Dec 2003 13:18:46 -0600, Chad Walstrom <[EMAIL PROTECTED]> said: 

> 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.

You talk as if the whole universe of window managers is merely
 gnome and kde.

manoj
-- 
We cannot command nature except by obeying her. Sir Francis Bacon
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

[Manoj Srivastava]

On Thu, 4 Dec 2003 15:44:56 -0500, Nathanael Nerode <[EMAIL PROTECTED]> said: 

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

I use neither gnome nor KDE. My window manager of choice shows
 me the Debian entries in the menu.  The code that would enable
 similar functionality from .desktop entries is not yet written.

manoj
-- 
Out of the same substances one stomach will extract nourishment,
another poison; and so the same disappointments in life will chasten
and refine one man's spirit, and embitter another's.  -- William
Matthews
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

[Manoj Srivastava]

On Thu, 4 Dec 2003 14:41:43 -0500, Matt Zimmerman <[EMAIL PROTECTED]> said: 

> 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?

I see a deb lying around on one of the machines at work -- and
 I do not trust some idiots who work for the gummint. Would be worth
 something to know the deb came from a real live debian developer. 

> 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.

Not quite. The signed deb is non-repudiable authorship -- nice
 to know whence the software cometh.

manoj
-- 
Short people get rained on last.
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

[Tore Anderson]

* Tore Anderson

 > * Andreas Metzler
 >
 >  >  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.

  Apologies for this misattribution, I was of course the author or the
 above paragraph, not Andreas.

-- 
Tore Anderson

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

[Tore Anderson]

* Andreas Metzler

 >  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.

* Andreas Metzler

 > No, I am sorry (and thanks for the offer). You effectively proposed
 > repacking from scratch, which requires amounts of work and testing I
 > am not willing to invest.

  I suspected as much.  Likewise I am not willing to do that work if the
 patch was stillborn irregardless of its quality.

* Andreas Metzler

 > If you think conf.d sucks like hell (where did I get this idea from? ;-)

  No Shit, Sherlock.  :)

 > try providing a patch for exim4-config-sane, [...]

  I thought about it for a while, but I don't really think that'd be a
 good idea.  Although I'd certainly use such a package myself, I believe
 it's not worth bloating the archive with yet another config package.
 Afterall, I would rather see the one that's already there removed and
 its functionality merged into exim4-base[0].

 > [2] Or simply do without making separate packages, making conf.d
 > yes/no a medium debconf-question.

  Low.  But other than that, I think this is an excellent idea,
 see below.

* Andreas Metzler (in <[EMAIL PROTECTED]>)

 > All they have to do is to install their configuration as
 > /etc/exim4/exim4.conf.

  I'm truly glad this is possible, and makes the conf.d stuff much
 more bearable.  However, it is still subpar, in my opinion, for if
 the user wants to do this, and implement minor modifications to
 the default config, he is totally on his own and won't get
 suggestions and fixes from you (as the maintainer) whenever the
 default configuration file changes.

  I got this idea that certainly will make me happy and which I
 think you might be inclided to consider for inclusion, though:

  We add a new option in update-exim4.conf.conf (and perhaps with
 a matching question in the debconf scripts, too) which, when
 enabled, would modify update-exim4.conf's behaviour to something
 like the following:

* Enables --keepcomments
* Suppresses the "generated dynamically" warning
* After the concatination, it installs /v/l/e/config.autogenerated
  into /e/e/exim4.conf, with the appropriate checks for user
  modifications (ucf could be used for this)

  (Alternatively, replace /v/l/e/c.a with $(tempfile) and set
   --output to the latter.)

  ..and I would be able to modify /etc/exim4/exim4.conf as I'm used to,
 and still have the full power of your debconf scripts at my disposal,
 in addition to being automatically notified (and given the opportunity
 to attempt a merge) of changes and (security) fixes to the default
 configuration.

  conf.d could still be the default.  No, wait, it -must- be the
 default if ucf is to be used.

  What do you think?

 [0] I might be dense, but I still don't see why it was split out from
 exim4-base in the first place.

-- 
Tore Anderson

一卡通

[徐小红]

Ç×°®µÄÓû§ÄúºÃ£¡

ÎÒ¹«Ë¾È«ÐÄÖÂÁ¦ÓÚ½»Í¨µç×Ó¹¤³Ì¡¢¸÷ÀàÍ£³µ³¡¡¢Â·ÇÅÊշѹÜÀíϵͳµÄÑо¿¡¢¿ª·¢¡¢Éú²úºÍÓ¦
Óã¬ÒÔ¼°±£°²¼à¿Ø¡¢·ÀµÁ±¨¾¯ÏµÍ³µÄ¹¤³ÌÊ©¹¤¡£ÑϸñÖ´ÐÐISO9001ÖÊÁ¿±£Ö¤Ìåϵ£¬²úÆ··¢Õ¹
½ô¸úÊг¡µ¼Ïò£¬²»¶ÏÑÐÖÆÊʺÏÖйú¹úÇéµÄ½»Í¨¼à¿Ø²úÆ·£¬Ìá¸ßÊг¡¾ºÕùÁ¦£¬²¢Îª¹ã´óÓû§Ìá
¹©´ÓÊÛÇ°×Éѯµ½Êۺ󹤳̰²×°Î¬»¤µÄÈ«·½Î»·þÎñ¡£ÎªÄúÌṩͣ³µ³¡ÊշѹÜÀíϵͳ½â¾ö·½°¸£¬
ͬʱΪÄãÌṩͣ³µ³¡¹ÜÀíÉ豸£¬É豸ÔËÐÐÎȶ¨¿É¿¿£¬ÓÐÑù°å¹¤³Ì²Î¿¼£¬Í£³µ³¡É豸Óбê×¼ÐÍ
ºÍ¼òÒ×ÐÍÉ豸µÈ£¬¹ºÂòÊýÁ¿ÀÛ¼Ó´ïµ½100Ì׿ɿª·Å²¿·ÝÈí¼þÔ´³ÌÐò¹²Ïí£¬²¢Ìṩͣ³µ³¡È«²¿
Éú²ú×ÊÁϺ͹©»õÖ¸ÄÏTI HID EM LEGIC MIFARE  CRYPTAG ¶Á¿¨¾àÀëÎÞÔ´¿¨¿É´ï10Ã×ÒÔÉÏÐÔÄÜ
Îȶ¨£»FLY SDK¡¢MOXAµÈÓ²¼þ£¬Ö§³ÖËùÓзբ»ú¡£Ìṩ¸ü¶àµÄÀ©Õ¹½Ó¿Ú£¬Ìṩ½Ó¿Ú¶¯Ì¬·½±ã
¶þ´Î¿ª·¢£¬ÈçÐè¸ü¶àµÄÍ£³µ³¡É豸×ÊÁÏÇëÓʼþͬÎÒÁªÏµ£º13088899268µÃµ½¸ü¶àµÄÖ§ÊõÖ§³Ö
ϵͳÌص㣺
±¾Èí¼þÕë¶Ô¹úÄÚÌØÊâÐÔ£¬¿ª·¢³öÒ»Ì׿ɹÜÀí´óÆû³µ¡¢Ð¡Æû³µ¡¢Ä¦Íгµ¡¢×ÔÐгµ¹ÜÀí¼°¾ü¾¯¡¢
ÊÐÕþ³µ¹ÜÀíÈí¼þ£¬°´Ê±ÊÕ·Ñ¡¢Ô¤¸¶·ÑºÍÔÂƱ¹ÜÀí£¬ÊÊÓÃÓÚÉú»îСÇø¡¢´óÏù«ÓÃÍ£³µ³¡¹ÜÀí¡£
ͬʱ¿ÉΪÄúÌṩһ¿¨Í¨ÅäÌ×É豸¡£
Ö÷Òª²úÆ·ÓУºIC¿¨ÖÇÄÜÍ£³µ³¡¹ÜÀíϵͳ£¬IC¿¨Ñ²¸üϵͳ£¬IC¿¨ÃŽû¿¼ÇÚϵͳ£¬IC¿¨POSÏû·Ñ
ϵͳ£¬ÊÊÓÃÓÚÉÌÒµ´óÏᢹ㳡£¬Éú»îСÇø³µÁ¾¹ÜÀí¡£ÖÇÄÜСÇøÒ»¿¨Í¨¹¤³Ì£¬ÖÇÄÜУ԰һ¿¨Í¨
¹¤³Ì£¬³µ¶Ó¹ÜÀíϵͳµÈ£¬²¢¿ÉÒÔΪ¹ó¹«Ë¾ÌṩÈí¼þÓ²¼þ¿ª·¢·þÎñ¡£
Ò²¿Éͨ¹ýwww.etmy.comµÃµ½¸ü¶à¼¼ÊõÖ§³Ö£¡
˳ףÉÌì÷£¡
   


ÉîÛÚ¾ÅÖñ¿Æ¼¼ÊµÒµÓкܹ«Ë¾
TEL£º0755-26016095  22039916
FAX£º0755-26016195
QQ£º18188937
ÊÖ»ú£º13088899268
ÁªÏµÈË£ººúÇ廪
[EMAIL PROTECTED]
MSN:[EMAIL PROTECTED]
µØÖ·£ºÉîÛÚÊÐÄÏɽÈí¼þÔ°¶«²à1¶°
[EMAIL PROTECTED]
Ò»¿¨Í¨

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

[cobaco]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2003-12-05 11:16, Andreas Tille wrote:
> their fine work.  I really love what they do and SkoleLinux is one of the
> most impressive derivatives of Debian, but it just does not (yet) fall
> under our definition.]

huh ?! How do you figure that?

Skolelinux install CD is basicly the first CD of a standard Debian (packages 
are reordered to have everything we need on the first CD). From the top off 
my head the only things in Skolelinux that are not in Debian are:

- - some hooks into d-i to do the debconf preseeding and choose the skolelinux 
flavor -> no standard way of doing this in Debian (yet)
- - a package to do the system-wide localization (discussion about merging this 
into language-env is taking place)
- - custom configurationfiles (through cfengine)
- - user-administration tool (still very much in development)
- -- 
Cheers, cobaco
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0GVu5ihPJ4ZiSrsRAqxTAJ9DSce0JxSr0BeAuNcXbhhrk+E7CACaAjMf
0xiINt6q1wF2aHdnXFAY4AY=
=Cwxy
-END PGP SIGNATURE-

adopting/kidnapping plucker, any objection?

[Ludovic Rousseau]

Hi,

The package plucker has 2 RC bugs. The lastest upload is dated 1 Dec
2002 (one year ago!). The package was orphaned (#160472, 11 Sep 2002)
and adopted by Pablo S. Torralba.

Pablo S. Torralba was/is not yet a DD and the last upload was sponsored
by Amaya Rodrigo Sastre.

The two RC bugs are very easy to fix but nothing was done.
I plan to do an NMU to correct these two RC bugs so that plucker can be
released in sarge.

I also plan to adopt plucker and package a new upstream version (Debian
plucker is 1.2 and upstream is 1.6).

If anyone has an objection to this adoption please reply on the list.

Regards,

-- 
 Dr. Ludovic Rousseau[EMAIL PROTECTED]
 -- Normaliser Unix c'est comme pasteuriser le camembert, L.R. --

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

[Mathieu Roy]

Zenaan Harkness <[EMAIL PROTECTED]> said:

> 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.

If it is just a matter of time, the transition can be done step by
step: the first step is just to say that this transition should be
done.

It doesn't need to be done in two days, does it? If new packages start
directly with .desktop and others packages move to .desktop in the
next year, it does not seems to be an awful load of extra work.



-- 
Mathieu Roy

  +-+
  | General Homepage:   http://yeupou.coleumes.org/ |
  | Computing Homepage: http://alberich.coleumes.org/   |
  | Not a native english speaker:   |
  | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english  |
  +-+

Re: Building a distribution from source?

[Steve Kemp]

On Thu, Dec 04, 2003 at 10:42:28PM -0500, Joey Hess wrote:
> That's what the debian-cd package is for.

   Thanks, that was exactly what I was looking for :)

Steve
--
Will code for food.  

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

[Mathieu Roy]

Steve Greenland <[EMAIL PROTECTED]> said:

> 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.

If everybody waits the .desktop to be supported by anybody else to
start supporting it, it will never be supported in any way.


-- 
Mathieu Roy

  +-+
  | General Homepage:   http://yeupou.coleumes.org/ |
  | Computing Homepage: http://alberich.coleumes.org/   |
  | Not a native english speaker:   |
  | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english  |
  +-+

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

[cobaco]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2003-12-05 11:06, Andreas Tille wrote:
> On Thu, 4 Dec 2003, cobaco wrote:
> > > There are no changes to Debian, because CDDs reside completely in
> > > main / testing /unstable as any other package.
> >
> > _ideally_ there are no changes. In practice there will be. For instance:
> > In skolelinux there's currently a package called
> > locale-config-skolelinux which sets up de default locale for all users.
> > This package is not part of Debian. Instead there's some discussion with
> > the relevant maintainer about merging locale-config-skolelinux,
> > language-env,  and the different user-language packages, with the hope
> > of eventually creating one package to set the default locale for both
> > single users and the system as a whole.
>
> Well, at least for my understanding SkoleLinux is not a "Custom Debian
> Distribution" exactly because they have packages which are not integrated
> in Debian.  This is no problem at all, but exactly here is the cruxial
> point of our definition. In my talk about CDD in Oslo I suggested the
> SkoleLinux people to take over the Debian-Edu ball because Raphael Herzog
> announced that he was running out of time.  

in the process of happening actually

>Debian-Edu *is* a CDD because
> it is completely inside Debian and 

hm, as far as I know Debian-edu is nothing more then a couple of 
task-packages at this point (and some education packages that got added to 
the archive)

> the suggestion is that SkoleLinux
> people patch the packages according to their needs.  

being done for Skolelinux, so basically you're saying that Skolelinux (or any 
other project aiming to be a CDD) is not a CDD untill they get everything 
they need back into Debian proper (which can take quite a while), even when 
we're trying to do so (and always have)?

>The *product* (one
> bootable CD) which contains Debian-Edu plus some extra packages which are
> necessary for whatever reason might be called SkoleLinux but this is not a
> CDD per the definition I was using in my talk in Oslo.  There was nobody
> who disagreed ...

hm, the definition I was using for a CDD would include Skolelinux because 
while not everything we do is in Debian _yet_we are trying to get everything 
included into Debian.

the responses to my earlier messages 
http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg00457.html
and
http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg00403.html
would seem to indicate (at least to me) that this view was shared

> > -> while being a subset is the goal we have in mind, it's not always the
> > actual situation. This is a consequence of
> > 1. inertia in Debian, because of which getting things changed takes a
> > while 2. the fact that some experimentation is often necessary to find
> > the right solution, leading to non-optimal solutions that "get the job
> > done" being used by the CDD in the meanwhile.
>
> Obviousely we use a different definition of CDD and this is causing the
> trouble.  If we should agree to your definition of CDD we have to come
> back for a common name for Debian-Jr, Debian-Med, Debian-Edu, Debian-Np,
> ...
er, these are subprojects producing CDD's (and Skolelinux is in the process 
of becoming Debian-Edu at this point see http://lists.debian.org/
debian-devel-announce/2003/debian-devel-announce-200309/msg00011.html). 

The produced CDD's might, or might not be a subset of Debian at any given 
time (at the moment at least the install process needs to be modified as 
there's no standard way to create an install/live-cd with a custom set of 
packages and configuration files). The important point here is, IMHO, that 
there is effort to get the missing pieces into Debian. Wether all pieces are 
already in Debian at a given point in time is I think unimportant (for 
defining a CDD anyways).
- -- 
Cheers, cobaco
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0G805ihPJ4ZiSrsRApNCAJ0SH9Swwjr3xmUGzj0gtFG3WL1GzwCeOQ2A
u5q9K7i+0qWT9QOgH7SqYCU=
=rwVw
-END PGP SIGNATURE-

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

[Mathieu Roy]

Andrew Suffield <[EMAIL PROTECTED]> said:

[...]


>> 
>> 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.

Do you truly think that it is better that every different people
looking after the exact same features writes each of them their own
software?

I'm more inclined to think that refusing to collaborate with other
people should be motivated by strong divergences on the goal to
reach and the method to follow ; not just because it is *possible* to
do everything on our own.

Are they strong divergences on the goal to rach and the method to
follow between Debian and freedesktop.org?


-- 
Mathieu Roy

  +-+
  | General Homepage:   http://yeupou.coleumes.org/ |
  | Computing Homepage: http://alberich.coleumes.org/   |
  | Not a native english speaker:   |
  | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english  |
  +-+

Re: [custom] Debian Enterprise - flavors

[Joerg Wendland]

Fabian Fagerholm, on 2003-12-04, 20:47, you wrote:
> 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?

Sure, but configuration of the samba package should be the
responsibility of this package.  What the Debian Enterprise project
should do is to work with the samba maintainer to achieve this and
maybe provide some sort of special configuration package.  This is what
I meant when writing about meta-packages and having work done by a
sub-project benefit the whole Debian system.

Joerg

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


signature.asc
Description: Digital signature

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

[Andreas Tille]

On Fri, 5 Dec 2003, cobaco wrote:

> On 2003-12-05 11:16, Andreas Tille wrote:
> > their fine work.  I really love what they do and SkoleLinux is one of the
> > most impressive derivatives of Debian, but it just does not (yet) fall
> > under our definition.]
>
> huh ?! How do you figure that?
Please read again my last two mails and assume that I know what SkoleLinux is.

Kind regards

   Andreas.

Re: [custom] Debian Enterprise - flavors

[Andreas Tille]

On Fri, 5 Dec 2003, Joerg Wendland wrote:

> Sure, but configuration of the samba package should be the
> responsibility of this package.  What the Debian Enterprise project
> should do is to work with the samba maintainer to achieve this and
> maybe provide some sort of special configuration package.  This is what
> I meant when writing about meta-packages and having work done by a
> sub-project benefit the whole Debian system.
I would see chances for extra configuration if there are more than one
package involved.  From personal experience I know the example that Zope
works fine together with apache.  You can define rewriting rules for
apache to the Zope server, use SSL through apache or do some caching.

Those kind of inter package configuration might make some sense.  Just
a rough guess some samba ldap relations might be possible.  Changing
configurations of single packages should be solved via the BTS ...

Kind regards

  Andreas.

-- 
Sie schaffen eine Wüste und nennen es Frieden.
-- Publius Cornelius Tacitus (55-120)

Re: recovery status update

[Roland Bauerschmidt]

James Troup wrote:
> As part of the recovery process, db.debian.org has migrated, both to a
> new host (because the old box was on it's last legs and HP kindly
> donated a shiny new one to replace it), and to a newer version of LDAP
> (because it was still using potato's OpenLDAP).

Which exact version of OpenLDAP and which database backend are you
using? The BDB backend has severe problems if incorrectly configured
(i.e. a DB_CONFIG file is missing or the cachesize specified there is
too small). We're working on that at the moment; libdb4.2 4.2.51 is
supposed to fix the problem, though a correctly cachesize is still
important for performance.

Roland

Re: Backporting 2.4.23 kernel packages

[Russell Coker]

On Fri, 5 Dec 2003 18:30, Andrew Pollock <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 05, 2003 at 05:59:40PM +1100, Russell Coker wrote:
> > On Fri, 5 Dec 2003 16:41, Andrew Pollock <[EMAIL PROTECTED]> wrote:
> > > So, I was wondering how to go about taking the source package for
> > > 2.4.23-686 (and the SMP version) and backport them to stable?
> >
> > Why not just use a machine running unstable to do the compile?
> >
> > I use unstable machines to compile all my kernels, they install and run
> > fine on woody systems.
>
> I presume I can lower the dependencies on things like modutils and whatnot
> down to the versions that are in stable with no ill-effects?

It only depends on coreutils|fileutils, so there's no problems in that regard.

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

[Mathieu Roy]

Joey Hess <[EMAIL PROTECTED]> said:

> Billy Biggs wrote:
>>   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?
>
> Some or all of: twm, pdmenu, blackbox, afterstep, fluxbox, gtk-menu,
> wmaker, fvwm2, enlightenment, etc, consult /etc/menu-methods for more.
> There are dozens of programs that use the debian menus that would have
> no reason to use the .desktop stuff.

Can you name the ones that are still developed in that list? Only one
half, I'm afraid. It is not a big surprise that wmaker does not
support a standard created more or less when the latest, only
bugfixes, release was published.

Why do you say that this programs would have no reason to use the
.desktop stuff? What reasons would they have to use the Debian Menu
instead?


-- 
Mathieu Roy

  +-+
  | General Homepage:   http://yeupou.coleumes.org/ |
  | Computing Homepage: http://alberich.coleumes.org/   |
  | Not a native english speaker:   |
  | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english  |
  +-+

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

[Mathieu Roy]

Andrew Suffield <[EMAIL PROTECTED]> said:

> 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.

Only if you disregard the last sentence of Raphael: "our menu system"
is definitely not going to be a standard (outside debian), is it? 

(In fact, only this last sentence is an argument, the other one is a
question.)

If there are no technical differences between two solutions but one is 
standard in many places (or going to be standard) and the other is
just known at home, which one is the best?
 

-- 
Mathieu Roy

  +-+
  | General Homepage:   http://yeupou.coleumes.org/ |
  | Computing Homepage: http://alberich.coleumes.org/   |
  | Not a native english speaker:   |
  | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english  |
  +-+

Re: adopting/kidnapping plucker, any objection?

[Amaya]

Ludovic Rousseau dijo:
> Why not. It may be a good solution.

IMHO, Co-m rules :-)

> I will upload my NMU to correct the two RC bugs in DELAYED/7-day as
> explained in [1]. So he has enough/some time to fix the bugs himself
> and upload a new version.

I will make sure he does ;-)

-- 
 .''`.A woman must be a cute, cuddly, naive little thing,
: :' :   tender, sweet, and stupid-- Adolf Hitler
`. `' Proudly running Debian GNU/Linux (Sid 2.4.20 Ext3)
  `-   www.amayita.com  www.malapecora.com  www.chicasduras.com

Re: adopting/kidnapping plucker, any objection?

[Ludovic Rousseau]

Le vendredi 05 décembre 2003 à 12:38:10, Amaya a écrit:
> I was out to the movies with him yesterday, he is not MIA or anything.
> We even talked about plucker's state. He is in the proccess of fixing
> the bugs.

Good news.

> Comanteinance may be an option?

Why not. It may be a good solution.

I will upload my NMU to correct the two RC bugs in DELAYED/7-day as
explained in [1]. So he has enough/some time to fix the bugs himself and
upload a new version.

Thanks,

[1] 
http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-nmu-when

-- 
 Dr. Ludovic Rousseau[EMAIL PROTECTED]
 -- Normaliser Unix c'est comme pasteuriser le camembert, L.R. --

Re: Backporting 2.4.23 kernel packages

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Russell Coker  <[EMAIL PROTECTED]> wrote:
>On Fri, 5 Dec 2003 18:30, Andrew Pollock <[EMAIL PROTECTED]> wrote:
>> On Fri, Dec 05, 2003 at 05:59:40PM +1100, Russell Coker wrote:
>> > On Fri, 5 Dec 2003 16:41, Andrew Pollock <[EMAIL PROTECTED]> wrote:
>> > > So, I was wondering how to go about taking the source package for
>> > > 2.4.23-686 (and the SMP version) and backport them to stable?
>> >
>> > Why not just use a machine running unstable to do the compile?
>> >
>> > I use unstable machines to compile all my kernels, they install and run
>> > fine on woody systems.
>>
>> I presume I can lower the dependencies on things like modutils and whatnot
>> down to the versions that are in stable with no ill-effects?
>
>It only depends on coreutils|fileutils, so there's no problems in that regard.

Hmm, last week I compiled a 2.4.23 kernel on my "unstable" desktop,
created a kernel-image package with make-kpgp, and it didn't
install on a plain woody machine. The "depmod" part failed.

On the 'stable' machine, I updated to modutils from Adrian Bunk's
sarge-to-woody backport archive, and then it suddenly worked.

Mike.

Re: Backporting 2.4.23 kernel packages

[Russell Coker]

On Fri, 5 Dec 2003 23:32, "Miquel van Smoorenburg" <[EMAIL PROTECTED]> wrote:
> Hmm, last week I compiled a 2.4.23 kernel on my "unstable" desktop,
> created a kernel-image package with make-kpgp, and it didn't
> install on a plain woody machine. The "depmod" part failed.
>
> On the 'stable' machine, I updated to modutils from Adrian Bunk's
> sarge-to-woody backport archive, and then it suddenly worked.

I've just noticed that all my woody machines have a modutils backport from 
Brian May.  Maybe this is a bug in kernel-package whereby it's not adding 
correct dependencies?

-- 
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: The term "Custom Debian Distribution"

[Zenaan Harkness]

On Fri, 2003-12-05 at 21:16, Andreas Tille wrote:
> [BTW, declaring that SkoleLinux as "no CDD" ... is one of the most
>  impressive derivatives of Debian, but it just does not (yet) fall under our
>  definition.]

So we have:

Debian, parent project & parent GNU/Linux Distribution
|
+-- Debian Related Projects (external/ non-official)
|   |
|   +-- (which may create) Derivative Debian Distros
|
+-- Debian Subprojects (official/ internal)
|
+-- (which may create) Custom Debian Distributions
|
+-- (which may provide) CDD "Flavours" on/after install


If there is a need for other terms (eg. metadistro, whatever), please
speak up/ add them in now if you are so inclined - carpe diem as they
say.

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: adopting/kidnapping plucker, any objection?

[Amaya]

Ludovic Rousseau dijo:
> The two RC bugs are very easy to fix but nothing was done.
> I plan to do an NMU to correct these two RC bugs so that plucker can
> be released in sarge.

I am not the one to decide, but go ahead.

> I also plan to adopt plucker and package a new upstream version
> (Debian plucker is 1.2 and upstream is 1.6).

I was out to the movies with him yesterday, he is not MIA or anything.
We even talked about plucker's state. He is in the proccess of fixing
the bugs. Comanteinance may be an option?

> If anyone has an objection to this adoption please reply on the list.

I don't care, but maybe he does ;-)

-- 
 .''`.A woman must be a cute, cuddly, naive little thing,
: :' :   tender, sweet, and stupid-- Adolf Hitler
`. `' Proudly running Debian GNU/Linux (Sid 2.4.20 Ext3)
  `-   www.amayita.com  www.malapecora.com  www.chicasduras.com

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

[Felipe Almeida Lessa]

On Fri, 05 Dec 2003 04:08:41 -0600, Manoj Srivastava <[EMAIL PROTECTED]>
escreveu:

> On Thu, 4 Dec 2003 13:18:46 -0600, Chad Walstrom <[EMAIL PROTECTED]> said: 
> 
> > 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.
> 
>   You talk as if the whole universe of window managers is merely
>  gnome and kde.

Now I'm using GNOME, but some time ago I have used XFce, Window Maker and
others. IMHO, we could have a script that converted new .desktop to old-style
Debian Menu while the WM don't understand .desktop. Or even better, we could
make it understand :-). 

OTOH, it could require some work. Actually, for me it would be very hard to make
any of these scripts, as I don't have the knowledge that would be necessary, so
I'm just saying my opinions.


[]'s,
Felipe Almeida Lessa.


pgpBRiDk6JzJB.pgp
Description: PGP signature

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

[Cameron Patrick]

On Fri, Dec 05, 2003 at 01:17:08PM +, Andrew Suffield wrote:

| Thing is, none of this matters. If upstream support .desktop files,
| then we just run them through the script that converts them to Debian
| menu entries while installing. dh_installmenu would be a good place to
| do this.
| 
| The extra features should be pretty simple to implement - just more
| text fields. That way we support the upstream menu entries in
| everything, not just kde and gnome.

Yeah, whatever.  Just so long as the current mess is resolved one way or
another, I don't have that strong a preference in favour of one system
or the other.  Given that extra features should be added to Debian's
menus anyway, and that no matter what happens there's going to be a need
to convert between .desktops and Debian menu entries, I can't see why it
should really matter which format is preferred.

Cameron.

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

[Andrew Suffield]

On Fri, Dec 05, 2003 at 03:02:42PM +0800, Cameron Patrick wrote:
> | Yeah, inverted the sense, you get the idea. We need both tools, at
> | which point there's no longer a reason not to just continue using the
> | existing Debian menu system.
> 
> Except that AFAIK .desktops are still semantically richer than the
> existing Debian system, and have more momentum behind them outside of
> Debian.  Upstream packages are much more likely to ship to .desktop
> files than they are Debian menu entries.  Admittedly I'm not convinced
> that they're ready enough in other ways to replace what we have now.

Thing is, none of this matters. If upstream support .desktop files,
then we just run them through the script that converts them to Debian
menu entries while installing. dh_installmenu would be a good place to
do this.

The extra features should be pretty simple to implement - just more
text fields. That way we support the upstream menu entries in
everything, not just kde and gnome.

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


signature.asc
Description: Digital signature

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

[Benj. Mako Hill]

On Fri, Dec 05, 2003 at 11:16:56AM +0100, Andreas Tille wrote:
> Please see my previous mail and try to accept that while absolutely
> incomplete the common entry point for CDDs is:
> 
> http://www.debian.org/devel/
> 
> under the topic "Projects".

Right, this page is (1) out of date and (2) really should be split to
differentiate Custom Distributions from non-CDD subprojects as you
mention. I've suggested this offhand before and the reception was a
little cold. Perhaps with the promise that will silence long threads
like this on -devel, people will be more receptive to the idea. :)

I will personally move forward with this as soon as I get access to
CVS.

> [BTW, declaring that SkoleLinux as "no CDD" I absolutely do not
> respect their fine work.  I really love what they do and SkoleLinux
> is one of the most impressive derivatives of Debian, but it just
> does not (yet) fall under our definition.]

Andreas, perhaps you missed this message:
  
http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200309/msg00011.html

Skolelinux took over for/merged with Debian-Edu in September. Through
Debian-Edu, they *are* listed and linked from the page you mention.

More importantly, Skolelinux has done more than almost any CDD in
terms of contributing back to Debian in both code and in
methodology. Their method of submitting wishlist bug reports with low
priority debconf questions is IMHO the most important way that CDDs
can integreate their work into Debian proper and that CDDs can
actually use to become pure Debian and earn their name.

Regards,
Mako

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



pgpTfhQepTwS0.pgp
Description: PGP signature

Question about contents of local release files

[Marc Haber]

Hi,

I have a local package pool which contains backports to woody. To be
able to do package pinning, I have Release files containing the
following:

Archive: woody
Component: main|contrib|non-free
Architectures: i386
Origin: mysite
Label: mysite/woody
Description: foobar

my sources.list lines are
deb http://my.local.mirror/debian woody main contrib non-free
deb http://my.local.mirror/mysite woody main contrib non-free


That way, I can do pinning with "Pin: release o=mysite,a=woody".
However, apt-cache policy does seem to display neither the Origin
component of an archive, nor the path after the host name. Thus I
cannot distinguish if the package being installed is plain woody, or
my local backport.

I am now wondering whether I made mistakes when I created my Release
files, or if apt is at fault for not displaying the entire path. What
is the Label for? Did I miss any docs?

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: Backporting 2.4.23 kernel packages

[Eduard Bloch]

#include 
* Andrew Pollock [Fri, Dec 05 2003, 03:41:14PM]:

> Is it as simple as taking the source package and building it in a stable
> pbuilder chroot, or is there more black magic involved with kernel packages?

AFAIK you need at least updated modutils and procps. And you should use
the default compiler in Woody to build it, otherwise your customers may
be not able to build additional kernel modules.

MfG,
Eduard.
-- 
 hobbies:  Linux, IRC -> ehm ja -> get a life!
 life? wasn das?
 ij: das is das problem vor dem du stehst wenn du im urlaub ohne computer 
bist
 CHS: urlaub? noch son unbekanntes wort... 

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> 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.

Any compromise happening before the package left ftp-master.d.o is not
covered by this. That means that if master is compromised a vulnerable
binary can be slipped into the archive and nothing will detect it.

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

A compromised master will be caught by this.

There is no protection possible against a compromised buildd,
compromised maintainer's workstation or a malicious maintainer short
of a intelligent AI. Saying something doesn't protect us against that
is a non argument.

To sum it up, advantages of signed debs are:

1. chain of trust from buildd to user
 or
   chain of trust from maintainer to user
(currently roughly present when debian-arch-changes mailinglist is subscribed)

2. chain of trust from ftp-master to user
(currently temporary present through Release.gpg as long as the deb is
in archive)

3. easy verification, automatic verification with users preferences

   NMUs, hijacks, adoptions, ... can be deteced and judged on a key by
   key basis if one desires

4. lasting signature

   The Release.gpg signatur only lasts as long as the file is in
   archive. Even changes to files without version change are
   undetected once Release.gpg has been rebuild.

5. Trust is kept for partial mirrors, apt-move, apt-zip, debian based
   distributions, custom CDs, ...

   E.g. Progency can use Debian debs and they can still be verified to
   be original. Or the daily D-I images.

Drawbacks:
132 Byte size increase per signature

MfG
Goswin

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> 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?

Because its way easier to put a script into /etc/apt/apt.conf.d/ that
runs debsigs-verify and compares a few settings from the control file
against the data on stdin for experiments.

MfG
Goswin

Re: debsums for maintainer scripts

[Goswin von Brederlow]

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

> * 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.

Does "dpkg --purge bla" actually remove /gaga/dada or leave it? Both
ways could leave blub broken. A Bug concerning Replaces has been filed
already and it would show up as false negative which can be verified
in detail by downloading the actual deb.

> > 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.

Package file md5sums don't work any better. You get the samme missing
or changed conffiles and replaced files as with the suggested
method. You loose nothing but gain tamper proofness.

> > > 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.

If you generate them when needed you can only say if tampering did
occur. If you generate them at installation time you can say what
files where tampered. If you don't want to spend the little time it
takes to calculate md5sums at install time you loose the ability to
pinpoint files. Its your choice.

> > 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 need to compute the md5sum of all files upon verifying them. When
you want to check the files. Thats for the option that you don't
generate them at install time.

> > You see, you safe the space for the md5sum, 
> 
> Huh?
> 
> # cat /var/lib/dpkg/info/*.md5sums | wc -c
> 9165770

That 10% of the precious space on my zip rescue disk. Not every
installation of Debian has space to waste.

> # df -h /usr
> /dev/hda2  27G  2.6G   23G  10% /usr
> 
> And the count of packages not having md5sums does 

Re: debsums for maintainer scripts

[Goswin von Brederlow]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> 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.

Thats the job of your lokal intrusion detection system. Providing
something for intrusion detection systems like md5sums after
configuring might be usefull but too often files are edit by hand
afterwards too.

> > 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
>  

Sort that by filename first and you have a reproducible list. You got
the drift.
 
> > 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]>  

:)

MfG
Goswin

Re: debsums for maintainer scripts

[Goswin von Brederlow]

Javier =?iso-8859-15?Q?Fern=E1ndez-Sanguino_Pe=F1a?= <[EMAIL PROTECTED]> writes:

> [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?

Thats why I want signatures so even after a compromise and reboot from
a good medium the debs or md5sum lists from the compromised system can
be trusted.

> 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)

Debian can provide such a database completly without any md5sums files
in the deb. They are as it is realy useless.

> > > 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)

Then write such a tool instead of wasting all mirror and users
bandwith and diskspace.

> >  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

If the vendor supplies the list you don't need any list in the debs
themself. Thanks for prooving our point.

> 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

You argue against people who are basically on your site. A known good
list of md5sums is usefull. A md5sums file inside the deb does not
provide this. We agree on that.

> 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.

And only users that want to check md5sum have to download thm.

> > > 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

Thats whats the thread was about most of the time.

> 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 

Re: Building a distribution from source?

[Goswin von Brederlow]

Steve Kemp <[EMAIL PROTECTED]> writes:

> On Fri, Dec 05, 2003 at 12:10:44PM +1100, Russell Coker wrote:
> > 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?
> 
>   Yes I am using slightly modified patches from http://www.immunix.org/.
> 
>   The propolice is something that I shall be evaluating next.
> 
> > How difficult is it to bootstrap this?  Can you compile glibc with these 
> > options without affecting anything else?
> 
>   So far I have built glibc with this modified GCC, (only so that I
>  could apply the "FormatGuard" patches which are designed to combat
>  format string attacks.  Recompiling glibc wasn't something that I
>  really wanted to try on the PII 233Mhz machine I have as my test box!
> 
>   Bootstrapping was very simple just a matter of applying the patche to
>  GCC and rebuilding it, then having installed it I rebuilt several test
>  packages which were exploitable previously and failed to be exploitable
>  afterwards.  (With the caveats that this patch doesnt protect against
>  all attacks).
> 
>   I confess that I haven't rebuilt _all_ the interesting packages yet
>  the kernel and X11 being the most likely to fail - but the packages
>  that I did build, bash, perl, etc did compile with no observed side
>  effects thus far.

If the ABI of libraries stays the same, sounds that way, bootstraping
is realy easy.

You can setup a normal system with wanna-build and a buildd and an
empty archive. You should patch the buildd to add a -0.0.1 or .0.1
debian version to each build. That way you can have the normal and
your hardened repository in the apt/sources.lists, install
normaly/security updates imediatly and update to hardened versions as
they are available.

MfG
Goswin

Re: kernel-patch-acl

[Christoph Hellwig]

On Fri, Dec 05, 2003 at 01:58:27PM +1100, Russell Coker wrote:
> Much of this patch is scheduled to be included in 2.4.24, so the work 
> required 
Who claims that? 

Re: Backporting 2.4.23 kernel packages

[Goswin von Brederlow]

Andrew Pollock <[EMAIL PROTECTED]> writes:

> On Fri, Dec 05, 2003 at 05:59:40PM +1100, Russell Coker wrote:
> > On Fri, 5 Dec 2003 16:41, Andrew Pollock <[EMAIL PROTECTED]> wrote:
> > > So, I was wondering how to go about taking the source package for
> > > 2.4.23-686 (and the SMP version) and backport them to stable?
> > 
> > Why not just use a machine running unstable to do the compile?
> > 
> > I use unstable machines to compile all my kernels, they install and run 
> > fine 
> > on woody systems.
> 
> I presume I can lower the dependencies on things like modutils and whatnot
> down to the versions that are in stable with no ill-effects?
> 
> Andrew

No. The manually added versioned depends are there for a reason.

MfG
Goswin

Re: Building a distribution from source?

[Goswin von Brederlow]

Steve Kemp <[EMAIL PROTECTED]> writes:

>   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.

You create a local apt repository. After that you just point the cd
creation to you repository instead of debian.

>   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.

You probably want to use the sarge Debian-Installer if you start
anything new. Its WIP but no point in getting used to something that
will be gone with sarge.

You need boot-floppies or debian-installer to creae the installation
software and debian-cd will create you a set of cds from the
installation software and your local repository.

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

Debian-cd can generate you jigdo files. The installation (both woody
and sarge) already use debootstrap, which just means you need the apt
repository you alreadycreaed to make cds.
 
>   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

Thats an option too and you get it for free.

MfG
Goswin

Re: debsums for maintainer scripts

[Goswin von Brederlow]

Anthony DeRobertis <[EMAIL PROTECTED]> writes:

> 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 the next rootkit will change md5sums files too...

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

Having md5sums signatures instead of files _inside_ the deb doesn't
prevent that.

MfG
Goswin

Re: debsums for maintainer scripts

[Goswin von Brederlow]

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

> * 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

Replaced files should be kept somewhere as long as the package being
replaced is installed.

Say B replaces A and you do the following:

dpkg -i A; dpkg -i B; dpkg --purge B

That should give exactly the same result as "dpkg -i A"
alone. Anything else would be a bug.

With replaced files being kept you can recalculate correct md5sum
lists for A and B at any time in any combination of installed
packages. But even if it fails due to some bug you will only get a
false negative. Then you download the debs and see what the problem
is.

> > > 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.

That all has to be tracked by dpkg already.

> 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.

MfG
Goswin

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

[Felipe Almeida Lessa]

Em Fri, 5 Dec 2003 21:55:21 +0800, Cameron Patrick escreveu:

> On Fri, Dec 05, 2003 at 01:17:08PM +, Andrew Suffield wrote:
> 
> | Thing is, none of this matters. If upstream support .desktop files,
> | then we just run them through the script that converts them to Debian
> | menu entries while installing. dh_installmenu would be a good place to
> | do this.
> | 
> | The extra features should be pretty simple to implement - just more
> | text fields. That way we support the upstream menu entries in
> | everything, not just kde and gnome.
> 
> Yeah, whatever.  Just so long as the current mess is resolved one way or
> another, I don't have that strong a preference in favour of one system
> or the other.  Given that extra features should be added to Debian's
> menus anyway, and that no matter what happens there's going to be a need
> to convert between .desktops and Debian menu entries, I can't see why it
> should really matter which format is preferred.

I agree, as far as GNOME and KDE stop using two kinds of menus at the same time.
What about adding {icon[1],i18n,etc} support to Debian Menu, as others said on
this thread? If we can automate .desktop => Debian process, so there's no *big*
reason to use freedesktop.org standard, as the main advantage would become the
fact of being a standard :-).

Also, the program icons in Debian menus is one thing that is annoying me since
I met Debian, as I can't use them in a larger size (aka in my desktop)
beautifully.

Cheers,
Felipe Almeida Lessa.

[1] I'm talking about categories, not programs.


pgpnLXfoz0Cw8.pgp
Description: PGP signature

数千中标方案,源码,商业计划书 23:24:13

[zhang]

尊敬的先生:
最低价格限量出售项目中标方案、软件源代码、技术教学,企业管理培训、个人能力训
练、商业计划书等精华资料光盘.
--

资料齐全、内容丰富。现全套一口价318元。如不放心者也可货到付款、绝对安全保证。
联系人: 张小姐 手机: 13066910205 电话 : 0755-26461572
QQ : 228725366 Mail: [EMAIL PROTECTED]
网址：http://zehuatech.vicp.net, http://www.zehuatech.com

--
(一) 产品说明
1、[2003] IT企业系统集成经典设计方案库与全面解决方案集（2CD）
本资料光盘精心收录了数十家公司，总计一千二百余个方案。文件解压后，容量共有
１６００Ｍ。涵盖了十余个行业的各类方案、投标书、内部绝密培训文档。均经过精心整
理分类而成，是您立于IT业不败之地的最有力武器。
对于新老手来说， 无论是撰写方案，还是投标书，有了这些"模板"，洋洋几十页，甚
至上百页的方案都可以轻易完成。足以让同事、领导为之侧目，是您快速提高自身实战技能、
加薪晋级的最有力武器。特别是各类公司的方案的撰写风格，更可以让您胸有成竹，轻松中
标，驰骋于商战海洋。

2、大型ERP系统/物资管理系统/电子商务/超市管理系统 (1CD)
容量超过460M，包括以下内容： 
☆ 大型ERP系统源码（含设计资料），基本模块都有，容量近200M； 
☆ 超市管理资料和管理系统设计文档； 
☆ 多个著名电子商务网站架构的源码和资料； 
☆ 物资管理系统(进销存)； ☆  控件库；  ☆  数据库；  ☆  相关说明；

3、创业必备数据和商业计划书大全 (1CD)
本套资料以商业计划书和创业数据为主干线，提供了创业和撰写商业计划书的丰富资
料，包括相关商业计划书的设计细节和完善的财务分析/投资回报分析等，分为商业计划书
参考案例／商业计划书样例库／商业计划书模板／风险投资公司名录／风险分析／管理类
电子文档／销售方案等十三个部分。

4、精选资料光盘。(1CD)
大量精心挑选的方案、源码、计划书，绝对精品。 

5、2500万精选绝不重复的邮件地址库、100款网络营销软件。(1CD)
---
(二) 付款方式：
您可以根据选择下面任一种卡号支付：
1   中国建设银行
开户行: 中国建设银行
　　帐号：  4367 4272 0005 2512 126
户名:   张圣慧
2  交通银行
   太平洋卡
   卡号: 4055 1286 3141 7160 4
   户名: 张圣慧

 
(三) 交付产品：
汇款后请及时致电给我们, 
我们确认你的汇款后,请将你的详细联系方式（地址、邮编、联系人、
电子邮件、电话等）邮件给我们，以便我们及时将您需要的产品发出。 

(四) 联系方式
联系人: 张小姐
手机: 13066910205
电话: 0755-26461572
QQ  : 228725366
Mail:[EMAIL PROTECTED]
---
如果本邮件不是你所需要的，敬请原谅，本邮件保证只发一次。

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

[Andreas Tille]

On Fri, 5 Dec 2003, cobaco wrote:

> hm, as far as I know Debian-edu is nothing more then a couple of
> task-packages at this point (and some education packages that got added to
> the archive)
I do not compare the quality of Debian-Edu or SkoleLinux - I just want to
use the right term.  Yes, SkoleLinux is currently more useable - no question.

> being done for Skolelinux, so basically you're saying that Skolelinux (or any
> other project aiming to be a CDD) is not a CDD untill they get everything
> they need back into Debian proper (which can take quite a while), even when
> we're trying to do so (and always have)?
That's the definition we agreed to.

> hm, the definition I was using for a CDD would include Skolelinux because
> while not everything we do is in Debian _yet_we are trying to get everything
> included into Debian.
If you would have read my previous mails you would have noticed, that we
use different definitions and that I want to clarify _the definition_ and
I'm not talking about the quality of SkoleLinux (which is damn good).

Kind regards

  Andreas.

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

[Steve Greenland]

On 05-Dec-03, 05:54 (CST), Mathieu Roy <[EMAIL PROTECTED]> wrote: 
> Steve Greenland <[EMAIL PROTECTED]> said:
> 
> > 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.
> 
> If everybody waits the .desktop to be supported by anybody else to
> start supporting it, it will never be supported in any way.

Are you being deliberately obtuse? I'm saying that when the other DE/WM
systems support .desktop files, either natively or via translataion
(which is exactly how the current Debian menu files are supported),
*along with the current menu files*, then individual packages can start
transitioning to the .desktop format without breaking every desktop
environment in Debian except GNOME and KDE. 

At best, this requires only (only!) a tool in the menu package that
reads .desktop and generates Debian menu files when appropriate, which
would be run out of the menu installation hook before the menu methods
are run to create the WM/DE native menu formats. But I haven't looked
at the menu system structure for a while, so someone who actually knows
what they're talking about should probably speak up now.

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: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[Ben Armstrong]

On Fri, Dec 05, 2003 at 03:20:45AM -0600, cobaco <[EMAIL PROTECTED]> wrote:
> _ideally_ there are no changes. In practice there will be.

Why?

> For instance:
> In skolelinux there's currently a package called locale-config-skolelinux
> which sets up de default locale for all users. This package is not part of
> Debian. Instead there's some discussion with the relevant maintainer about
> merging locale-config-skolelinux, language-env,  and the different
> user-language packages, with the hope of eventually creating one package to
> set the default locale for both single users and the system as a whole.

Then that discussion needs to be resolved so that a solution can be made 
that is in Debian main.

I'm sorry, but I really have a hard time with this.  A Custom Debian
Distribution is nothing more than what is provided within Debian proper, as
Andreas said.  While a Debian subproject may consider and make use of stuff
in development that is outside of Debian while transitioning it to be "pure
Debian", the formal definition of CDD cannot include materials outside of
Debian main, otherwise it is not Debian, and cannot contain the name
"Debian" in its title.  Skolelinux, as you say, is a perfect example of
this.  Skolelinux is not a CDD.  It is a project in transition to becoming a
CDD.  As I understand it, Skolelinux is not entirely there yet, for the
reasons you have already mentioned.  It has its own history and its own 
needs which are for the moment unresolvable within Debian.  Furthermore, it 
does not contain 'Debian' in its title, so there is no confusion.  This is 
clearly a Debian-derivative, not a CDD.

> - -> while being a subset is the goal we have in mind, it's not always the
> actual situation. This is a consequence of
> 1. inertia in Debian, because of which getting things changed takes a while
> 2. the fact that some experimentation is often necessary to find the right
> solution, leading to non-optimal solutions that "get the job done" being
> used by the CDD in the meanwhile.

Sure, and that's what the 'experimental' ftp archive is for.

Now, I'm not saying that Debian derivatives shouldn't exist.  It is
important to acknowledge that they do, but at the same time work towards
eliminating, as much as possible, the need for their existence outside of
Debian main.  Not all reasons for being a derivative (or "Debian-based 
distribution") can be eliminated (such as the inclusion of non-free or 
contrib software).  However, I believe the reasons for Skolelinux not being 
a CDD can and will eventually be resolved.

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

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

[Andreas Tille]

On Fri, 5 Dec 2003, Benj. Mako Hill wrote:

> I will personally move forward with this as soon as I get access to
> CVS.
Thanks.  This would be much appreciated.

> Andreas, perhaps you missed this message:
>   
> http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200309/msg00011.html
Definitely not because I'm very happy about it.

> Skolelinux took over for/merged with Debian-Edu in September. Through
> Debian-Edu, they *are* listed and linked from the page you mention.
Yes and you might remember that exactly this was the hint I gave in Oslo
in the discussion of my talk.

> More importantly, Skolelinux has done more than almost any CDD in
> terms of contributing back to Debian in both code and in
> methodology. Their method of submitting wishlist bug reports with low
> priority debconf questions is IMHO the most important way that CDDs
> can integreate their work into Debian proper and that CDDs can
Definitely!
That's why I feeled obliged to add the remark that I greatly appreciate
the work of the SkoleLinux people and that they probably did more for
Debian than any CDD is out of any question.

> actually use to become pure Debian and earn their name.
  ^^
This is the keyword why I think that SkoleLinux is not yet a CDD.  They
do not have a webpage under www.d.o, no mailing list under lists.d.o
(which is not the most important criterium).  IMHO the key feature is
that SkoleLinux is not yet visible once you install plain Debian neither in
tasksel nor in the form of metapackages (I do not mind whether they adopt
edu-* name space or just use their own), etc.   Regarding to tasksel
there is a an open bug #186085 which definitely needs support by the
other CDD-people.  Once SkoleLinux is for instance mentioned in tasksel
(see #186085) I would call it CDD.

To be a CDD or not is no question of honor - its a question of the placement
related to Debian.  Its really no shame to be no CDD (you might even have 
reasons
to make the work better outside).

Kind regards

   Andreas.

Re: debsums for maintainer scripts

[Javier Fernández-Sanguino Peña]

(no need to CC: me as I'm subscribe)

> > 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?
> 
> Thats why I want signatures so even after a compromise and reboot from
> a good medium the debs or md5sum lists from the compromised system can
> be trusted.

You can still have a valid signature but an invalid package (out of date 
with known security holes) installed, though.

> > 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)
> 
> Debian can provide such a database completly without any md5sums files
> in the deb. They are as it is realy useless.

No they are not, but it seems you did not understand my example at all.

> > > > 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)
> 
> Then write such a tool instead of wasting all mirror and users
> bandwith and diskspace.

I'm asking Debian mirrors to handle the file with the whole list of 
md5sums. Not users. Still, you are saying that users would need to have a 
_complete_ copy of the archive to generate that list or compare it against 
a local system.

> > 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
> 
> If the vendor supplies the list you don't need any list in the debs
> themself. Thanks for prooving our point.

You do want that list too, again, you didn't read or understand my example. 
I'm not proving your point.

> You argue against people who are basically on your site. A known good
> list of md5sums is usefull. A md5sums file inside the deb does not
> provide this. We agree on that.

(I guess site -> side?)
We don't agree in this, I want both: the known good list of md5sums 
provided in Debian mirrors and the md5sums file inside the debs to use them 
both for comparisons against the files and against themselves.

> > 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
> 
> Thats how it is now. in package md5sum files, what this is all about,
> doen't change that a bit.

No, it is not. That information can be easily extracted to a single file 
and provided in the mirror so you can download that file instead of all the 
packages.

> > stable+security updates, how would you remove the false positives in your
> > above example? 
> 
> You read every single file thats changed and find out if that is an attack.

What do you mean read? Do you mean checking the timestamps? Checking the 
md5 hashes? I'm sorry but I don't see your point.

> > 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.
> 
> That means you throw th local one away and download a known good one.

No, it meas I use both to determine if the local database has been tampered 
or not. The fact that the local database has been tampered means I cannot 
trust it, but it also highlights a targeted attack (current rootkits do 
not mess with package information)

(...)
> (1) downloads you a known good copy which mans downloading all debs
> as it is now.

I'm asking for two things here, as I said before, md5sums in the .debs 
and a Contents-md5sums file in the mirrors which would be downloaded in (1)
you wouldn't need to donwload the archive.

> > > > So my vote goes to adding md5sums to policy.
> > > 
> > >   We still don't vote on technical issues, thank god.
> > 
> > It was just an expression, obviously. Maybe it's not translatable. 
> > 
> > Friendly 
> > 
> > Javi
> 
> You vote for providing md5sums files seperatly from the debs and not
> in the debs (and you probably would still agree by just providing a
> signature for locally stored/generated md5sum file verification). So
> your on our side.

Well, there are not really sides here. But again:

- I want md5sums to be stored in the local filesystem, I don't really care 
if they are insid

Re: Building a distribution from source?

[Steve Kemp]

On Fri, Dec 05, 2003 at 10:20:19AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:

> > I believe that our GCC packages already have propolice patched in but not 
> > enabled.  Therefore it should be a much easier change to make for it to be 
> > included.
> 
> This is true, debian/patches has a line for propolice (currently commented 
> out)

  I've just spent several hours building a version of gcc v3.3 with this
 enabled, and tested it out on some packages.

  So far it appears to work, it will abort "attacks" and it hasn't
 demonstrated any obvious side effects.  I'm not sure that I can use it
 in practise, I will have to see how easy it is to get built under
 Debian Stable which really is my target environment.

  I'll continue playing with it and try to test it with more packages,
 reporting back here if there's anything interesting to say.

> "They're large patches, with no testing on most architectures.  They
> touch platform independent code.  If it really did do nothing without
> the option, and we were convinced of that, then maybe they could be
> applied - I'm not convinced."

  The naive thing for me to say is that no testing will happen until
 it is enabled and deployed.  I'm sure this has been considered though
 ..

Steve
--

Re: debian pxe dhcp netinstall (debconf enterprise fai etc.)

[Paul Telford]

On Fri, 5 Dec 2003, Chad Walstrom wrote:

> I was intrigued by Progeny's autoinstall Python script, but never had a
> chance to look into it further.

Progeny no longer maintains autoinstall, but I have picked it up and 
continue to use, maintain, and enhance it.  If you haven't looked at it in 
a while it might be worth revisiting.  I uploaded a new version a month or 
two ago which fixes some of the deficiencies of previous versions.  

I also received a comment from a user last week stating that they are
using autoinstall with PXE and it is working great.  I'm using autoinstall
via a single 1.44M floppy every day to deploy various machines and it all
works as expected -- my machines are up and running in just a few minutes,
completely hands-free.



 Paul.


--
Paul Telford | 1024D/431B38BA | [EMAIL PROTECTED] | [EMAIL PROTECTED]
   C903 0E85 9AF5 1B80 6A5F  F169 D7E9 4363 431B 38BA

Re: debian pxe dhcp netinstall (debconf enterprise fai etc.)

[Chad Walstrom]

On Fri, Dec 05, 2003 at 01:13:57AM -0800, Mark Ferlatte wrote:
> FAI is good, but it doesn't handle updating the systems once you have
> them installed.

You're absolutely right.  The cfengine scripts are also slightly
difficult to re-use after the initial installation.  A good cfengine
setup is hard to beat for managing multiple boxes, but cvsup is
certainly a good way to do it.

It just goes to show that there is no One Right Way(tm) to do things.
I'm excited about debian-installer's modularity.  It has the potential
to do installs the "right way".

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


pgpX7N1tLJeLd.pgp
Description: PGP signature

Re: Revival of the signed debs discussion

[Matt Zimmerman]

On Fri, Dec 05, 2003 at 12:24:07AM +0100, Goswin von Brederlow wrote:

> Matt Zimmerman <[EMAIL PROTECTED]> writes:
> 
> > 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.
> 
> Any compromise happening before the package left ftp-master.d.o is not
> covered by this. That means that if master is compromised a vulnerable
> binary can be slipped into the archive and nothing will detect it.

So the only real-world attack which is addressed by signed debs is an
ftp-master compromise?  This is the only answer you have given to my
original question.

-- 
 - mdz

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

[Tom]

On Fri, Dec 05, 2003 at 11:36:20AM -0400, Ben Armstrong wrote:

> Then that discussion needs to be resolved so that a solution can be made 
> that is in Debian main.

It's useful to try to clarify the terms so people can speak the same 
language, but as soon as you categorize anything somebody's going to 
come out with something which fits in multiple categories.

Anything which isn't just a subset of Debian will ultimately just be a 
distraction, in which case the # of "flavors" is the cardinality of the 
power set of packages. :-)

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

[Ben Armstrong]

On Fri, Dec 05, 2003 at 09:23:52AM -0600, cobaco <[EMAIL PROTECTED]> wrote:
> On 2003-12-05 11:06, Andreas Tille wrote:
> > Well, at least for my understanding SkoleLinux is not a "Custom Debian
> > Distribution" exactly because they have packages which are not integrated
> > in Debian.  This is no problem at all, but exactly here is the cruxial
> > point of our definition. In my talk about CDD in Oslo I suggested the
> > SkoleLinux people to take over the Debian-Edu ball because Raphael Herzog
> > announced that he was running out of time.  
> 
> in the process of happening actually

A move that I'm happy to see is happening.

> >Debian-Edu *is* a CDD because
> > it is completely inside Debian and 
> 
> hm, as far as I know Debian-edu is nothing more then a couple of 
> task-packages at this point (and some education packages that got added to 
> the archive)

Which doesn't change Andreas' point.  It may be a lame CDD, but it is still
a CDD. :)

> > the suggestion is that SkoleLinux
> > people patch the packages according to their needs.  
> 
> being done for Skolelinux, so basically you're saying that Skolelinux (or any 
> other project aiming to be a CDD) is not a CDD untill they get everything 
> they need back into Debian proper (which can take quite a while), even when 
> we're trying to do so (and always have)?

Again we trip across the distinction between organizational and technical
terms.  Skolelinux has not yet produced a CDD release (the technical term),
but it is a work-in-progress.  Organizationally, Skolelinux is a subproject
that is working to produce a CDD because that is its stated goal.

> >The *product* (one
> > bootable CD) which contains Debian-Edu plus some extra packages which are
> > necessary for whatever reason might be called SkoleLinux but this is not a
> > CDD per the definition I was using in my talk in Oslo.  There was nobody
> > who disagreed ...
> 
> hm, the definition I was using for a CDD would include Skolelinux because 
> while not everything we do is in Debian _yet_we are trying to get everything 
> included into Debian.

Sure, the work-in-progress is a CDD.  Existing releases, however, are not.

> the responses to my earlier messages 
> http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg00457.html
> and
> http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg00403.html
> would seem to indicate (at least to me) that this view was shared

I still have a problem with "whenever possible".  You seem to be reserving
the right to always include some material in releases of the CDD that is
outside of Debian.  You cannot call any release of Debian including material 
outside of Debian main "Official Debian".  That isn't just splitting hairs.  
That's how it is described here:

http://www.debian.org/CD/vendors/

Depending on whether you are talking about a CD of Skolelinux as a stable or
developer's release, it is either a "Vendor Release" or "Development
Snapshot" according to the descriptions on this page.

> The important point here is, IMHO, that 
> there is effort to get the missing pieces into Debian. Wether all pieces are 
> already in Debian at a given point in time is I think unimportant (for 
> defining a CDD anyways).

For defining a subproject working on a CDD, no.  But intent doesn't make any
difference to the end-user if release time rolls around and stuff outside of
Debian is still being included.  At this point, what the users have in their
hands is a distribution derived from Debian.  For example, if they find bugs
in any of the material outside of Debian, it must be dealt with outside of
the usual Debian structures (i.e. bts makes no provision for filing bugs
against packages that aren't actually in Debian).

Regards,
Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

下周六来找你玩！

[ght]

这些天你跑去哪里了，很久没找你一起玩了，真的很想念。
我这几天也没干什么，老是窝在家里上网，最近发现了一个很有意思的网站，叫什么"精品世
界（http://www.52jp.com）";
他上面的东西很好玩，比如说，有装在相机上能拍透视效果的红外透视镜头，有很好玩的微型无线摄像机，
有能观测十几公里的望远镜，有能防偷拍、防窃听的探测狗，还有打电话时能变声音的电话变声器，更有……嘿嘿……
能让女孩子欲乱情迷的催情药哦。
我自己也买了一个针孔摄像机玩，还拍了一些很有意思的"电影"哦，下周六我来找你玩，把片子带来也分享
给你看看，这可是我的秘密宝贝哦，要不是咱俩关系好，我才不拿出来呢：）

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:
>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.

Unfortunately, that doesn't work. apt immediately bombs out with "E:
Internal Error, Couldn't configure a pre-depend", while installing all
three packages using dpkg simultaneously doesn't work as well:

|[3/[EMAIL PROTECTED] woody]:/var/cache/apt/archives$ sudo dpkg --install 
exim4-base_4.30-0.unreleased_i386.deb exim4-config_4.30-0.unreleased_all.deb 
exim4-daemon-light_4.30-0.unreleased_i386.deb 
|(Reading database ... 4426 files and directories currently installed.)
|Preparing to replace exim4-base 4.30-0.unreleased (using 
exim4-base_4.30-0.unreleased_i386.deb) ...
|Unpacking replacement exim4-base ...
|Preparing to replace exim4-config 4.30-0.unreleased (using 
exim4-config_4.30-0.unreleased_all.deb) ...
|Unpacking replacement exim4-config ...
|dpkg: regarding exim4-daemon-light_4.30-0.unreleased_i386.deb containing 
exim4-daemon-light, pre-dependency problem:
| exim4-daemon-light pre-depends on exim4-base (>= 4.30)
|  exim4-base is unpacked, but has never been configured.
|dpkg: error processing exim4-daemon-light_4.30-0.unreleased_i386.deb 
(--install):
| pre-dependency problem - not installing exim4-daemon-light
|dpkg: dependency problems prevent configuration of exim4-base:
| exim4-base depends on exim4-daemon; however:
|  Package exim4-daemon is not installed.
|dpkg: error processing exim4-base (--install):
| dependency problems - leaving unconfigured
|Setting up exim4-config (4.30-0.unreleased) ...
|
|Errors were encountered while processing:
| exim4-daemon-light_4.30-0.unreleased_i386.deb
| exim4-base
|[4/[EMAIL PROTECTED] woody]:/var/cache/apt/archives$ 

Looks like we have the following problem:
- exim4-daemon-light and exim4-base are to be installed
- exim4-daemon-light is not unpacked because it pre-depends on
  exim4-base.
- exim4-base can not be configured because exim4-daemon-light is not 
  yet unpacked.

This seems like the clash cannot be solved. Or does anybody have any
ideas?

Do I see correctly that the default MTA is selected by means of
package priority, like that the only MTA of Priority: Important is the
default? Is there any other means of selecting the default MTA?

And do I see correctly that the rule "Packages must not depend on
packages with lower priorities" is a legacy from the times where CD
makers were not able to follow Dependency chains?

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: debsums for maintainer scripts

[Bernhard R. Link]

* Goswin von Brederlow <[EMAIL PROTECTED]> [031205 16:11]:
> With replaced files being kept you can recalculate correct md5sum
> lists for A and B at any time in any combination of installed
> packages. But even if it fails due to some bug you will only get a
> false negative. Then you download the debs and see what the problem
> is.

But false negatives cause work. Why do you want to cause false
negatives?

I'm still hoping to see you giving a single reason, why the current
robust solution, implemented by a vast majority packages, should be
replaced by something else. Where this something else needs substantial
computing power, will need much work to be usable in all cases and 
is complex enought that it will eventually fail.

The only thing having any similarity to a reason was the size of those
files. But seeing how small they are, I don't think this can be the
reason. So what did I miss?

Hochachtungsvoll,
  Bernhard R. Link

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

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

[Marc Haber]

On Thu, 04 Dec 2003 19:24:28 +0100, Marc Haber
<[EMAIL PROTECTED]> wrote:
>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.

After looking into that matter, I am not sure if this will actually
help. Calling -config's "postinst" from -daemon's postinst will only
help if it is guaranteed that all packages in the dependency cycle are
unpacked before the first configure attempt is started. Policy 7.2 is
amazingly fuzzy in that regard, only saying that "packages in an
installation run are usually all unpacked first and all configured
later".

An additional problem is debconf. If dpkg-preconfigure is used, all
packages config scripts run before the actual packages are unpacked.
This way, we can rely on all questions being asked before
configuration is started. But if dpkg-preconfigure is not used, the
only thing we can rely on - if I understand correctly - is that
foo.config is run before foo.postinst. We'd need to use hooks in the
config scripts to invoke -config's config from -daemon's config.

We would also have to dream up some magic code to handle the
parameters handled down to postinst and config, most notably the
version numbers.

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

[Chad Walstrom]

On Fri, Dec 05, 2003 at 04:08:41AM -0600, Manoj Srivastava wrote:
> > ... 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.
> 
>   You talk as if the whole universe of window managers is merely
>  gnome and kde.

I understand how you might get that, but you have to admit that they are
the most visible of the desktop environments.  I didn't mention window
managers specifically because I don't see the need to make the
distinction in this case.  The .desktop files has the same goal and
focus as a .menu file -- providing a convenient interface to finding and
launching applications, so let's keep that the focus of the discussion.

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


pgpQm2EmGr3TA.pgp
Description: PGP signature

Re: debian pxe dhcp netinstall (debconf enterprise fai etc.)

[Mark Ferlatte]

Chad Walstrom said on Fri, Dec 05, 2003 at 10:05:15AM -0600:
> On Fri, Dec 05, 2003 at 01:13:57AM -0800, Mark Ferlatte wrote:
> > FAI is good, but it doesn't handle updating the systems once you have
> > them installed.
> 
> You're absolutely right.  The cfengine scripts are also slightly
> difficult to re-use after the initial installation.  A good cfengine
> setup is hard to beat for managing multiple boxes, but cvsup is
> certainly a good way to do it.

I like cfengine, but I haven't done anything in production with it yet.

> It just goes to show that there is no One Right Way(tm) to do things.

Indeed.  But arguably there are better ways; it would be cool if Debian
Enterprise would help support them.

I've been spending a lot of time thinking about this sort of automatic machine
maintanence; there's a lot of tools out there, but they all have weak spots
here and there.  There also doesn't seem to be many places where people are
talking about this stuff, either; many seem to go out and roll their own
system, which is fine, but then all the poor admins end up re-inventing the
wheel, which is not fine.

M, wheel re-inventor.


pgpJsP4LKBH6w.pgp
Description: PGP signature

Re: Building a distribution from source?

[Jakob Lell]

Hello,
maybe Adamantix is what you are wanting to do. It is based on Debian woody and 
uses kernel and gcc patches to improve security. At the moment you need to 
install a normal Debian woody and then upgrade. However, you might create 
installation CDs yourselve. For more information about Adamantix, see
http://trusteddebian.org/

Regards
 Jakob

Re: adopting/kidnapping plucker, any objection?

[Graham Wilson]

On Fri, Dec 05, 2003 at 01:44:40PM +0100, Ludovic Rousseau wrote:
> Le vendredi 05 décembre 2003 à 12:38:10, Amaya a écrit:
> > I was out to the movies with him yesterday, he is not MIA or anything.
> > We even talked about plucker's state. He is in the proccess of fixing
> > the bugs.
> 
> [...]
> 
> I will upload my NMU to correct the two RC bugs in DELAYED/7-day as
> explained in [1]. So he has enough/some time to fix the bugs himself and
> upload a new version.

Can that be done with the FTP queue? But regardless, 0-day NMUs start in
about 6 hours, so I'd upload them there, especially since there are RC
bugs.

-- 
gram


signature.asc
Description: Digital signature

Re: Revival of the signed debs discussion

[Anthony DeRobertis]

On Fri, 2003-12-05 at 04:54, Manoj Srivastava wrote:

> > 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.
> 
>   Not quite. The signed deb is non-repudiable authorship -- nice
>  to know whence the software cometh.

No it isn't. For it to be non-repudiable, you'd have to demonstrate that
the key has not been compromised; that the developer knew what he was
signing (as opposed to a trojaned gpg telling him one thing while doing
another); etc. Proving those is quite impossible --- especially if he
doesn't want you to: He can always compromise his own key, on purpose.


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

Re: debsums for maintainer scripts

[Anthony DeRobertis]

On Thu, 2003-12-04 at 19:06, Goswin von Brederlow wrote:

> > 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 the next rootkit will change md5sums files too...

rpm has had md5sums for a good, long time. Yet, when someone asks me
'why did my box break', its amazing how many times asking rpm to verify
the md5sums finds ps, ls, etc. modified.

Most attackers I've had to clean up after don't have a CLUE as to what
they're doing. I find it difficult to believe that will change.

> 
> > And they do help when you suspect hardware troubles, too.
> 
> Having md5sums signatures instead of files _inside_ the deb doesn't
> prevent that.

If I have md5sums of each file, I know which files are damaged. That's
quite different than knowing "something in xserver-xfree86 changed."


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

Re: debsums for maintainer scripts

[Anthony DeRobertis]

On Thu, 2003-12-04 at 11:11, Manoj Srivastava wrote:

>   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?

I just took an md5sum of every file on my system. Including things like
/var and /home that aren't part of packages. It's 13M, uncompressed.
Compressed, it's 3.5M. 

If we were really worried about archive size, an md5sum is 16 octets.
It's hard to see that mattering to overall archive size.

> > 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.

Have you ever met any bit changes that defeat md5? Didn't think so.


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

Re: debsums for maintainer scripts

[Anthony DeRobertis]

On Wed, 2003-12-03 at 20:46, Goswin von Brederlow wrote:

> Because without preventing tampering (even accidental) of the md5sums
> file its quite useless.

I want to check if anything on my system was corrupted after a recent
bout of fun with fsck. The md5sums are quite useful for that.


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

Re: Building a distribution from source?

[Steve Kemp]

On Fri, Dec 05, 2003 at 06:37:47PM +0100, Jakob Lell wrote:

> maybe Adamantix is what you are wanting to do. It is based on Debian woody 
> and 
> uses kernel and gcc patches to improve security. At the moment you need to 
> install a normal Debian woody and then upgrade. However, you might create 
> installation CDs yourselve. For more information about Adamantix, see
> http://trusteddebian.org/

  It is certainly similar to what I would like to see/work on.

  But Adamantix there does seem little liklihood of their work coming
 back into Debian proper, and that's my single biggest problem with it.

  (Ignoring my personal dislike of RSBAC).

Steve
--

Re: xdm: init script's execution can be terminated prematurely if invoke-rc.d run from child process of xdm

[Dan Jacobson]

Maybe remove the pid file before killing, not after?  If it resists
our best attempts at killing. including -9, that would be a different
bug, and leaving a pid file would be useless anyway? Just a guess.

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

[Joey Hess]

Mathieu Roy wrote:
> If it is just a matter of time, the transition can be done step by
> step: the first step is just to say that this transition should be
> done.
> 
> It doesn't need to be done in two days, does it? If new packages start
> directly with .desktop and others packages move to .desktop in the
> next year, it does not seems to be an awful load of extra work.

If that happened then we would, for an undefined length of time that
would probably span a Debian release, have two divergent sets of menus,
with some programs randomly on the Debian menus, and some programs
randomly on the free desktop menus. This would be unusable, and a
bad regression.

You speak of a transition, but I see no transition plan here. I suppose
that this thread is useless, and someone will eventually write code, and
that person will be the one who decides how it works.

-- 
see shy jo


signature.asc
Description: Digital signature

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

[Joey Hess]

Mathieu Roy wrote:
> >>   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?
> >
> > Some or all of: twm, pdmenu, blackbox, afterstep, fluxbox, gtk-menu,
> > wmaker, fvwm2, enlightenment, etc, consult /etc/menu-methods for more.
> > There are dozens of programs that use the debian menus that would have
> > no reason to use the .desktop stuff.
> 
> Can you name the ones that are still developed in that list? Only one
> half, I'm afraid. It is not a big surprise that wmaker does not
> support a standard created more or less when the latest, only
> bugfixes, release was published.

Every peice of software I listed is part of Debian, and supported by
Debian.

> Why do you say that this programs would have no reason to use the
> .desktop stuff? What reasons would they have to use the Debian Menu
> instead?

Some of the listed programs have nothing to do with a desktop menu
standard, and have zero chance of supporting it upstream. The Debian
menu system creates native config files in the format these programs
use.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> On Fri, Dec 05, 2003 at 12:24:07AM +0100, Goswin von Brederlow wrote:
> 
> > Matt Zimmerman <[EMAIL PROTECTED]> writes:
> > 
> > > 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.
> > 
> > Any compromise happening before the package left ftp-master.d.o is not
> > covered by this. That means that if master is compromised a vulnerable
> > binary can be slipped into the archive and nothing will detect it.
> 
> So the only real-world attack which is addressed by signed debs is an
> ftp-master compromise?  This is the only answer you have given to my
> original question.

And its a lasting signature.

Currently you can't check the debs in your apt-cache if they are a bit
older. And you can't check snapshot.debian.net for compromises.

MfG
Goswin

master program in germany

[sami gulbay]

: : Hi, 
: : I am studying food 
engineering at Gaziantep university in Turkey. .I will graduate next year and I 
am interested in continuing my education(master)in Germany.Please send me the 
required information for doing master there and fees of that and all information 
regarding application forms and so on.
: : Thank you in 
advance:).
Sami gulbay 
[EMAIL PROTECTED]

Re: Building Debian Completely From Source

[Matt Zimmerman]

On Fri, Dec 05, 2003 at 01:53:11PM -0600, John Goerzen wrote:

> The nearest I have seen is fink, but I know little about it.
> 
> Am I missing something?

apt-src, apparently.

-- 
 - mdz

uploading problems and massive email floods

[Ben Pfaff]

Following the suggestion in the recent message to
debian-devel-announce, I tried using dupload to upload to the
anonymous queue.  Soon I got back this message:

--
Subject: Processing of autoconf_2.58-9_i386.changes

PGP/GnuPG signature check failed on autoconf_2.58-9_i386.changes

Could not read key from file 
'/org/queued/debianqueued-0.9/./debian-keyring.pgp'.

WARNING: Can't find the right public key-- can't check signature integrity.
gpg: Signature made Wed Dec  3 17:21:24 2003 EST using RSA key ID 797E641D
gpg: Can't check signature: public key not found
(Exit status 2)
autoconf_2.58-9_i386.changes has bad PGP/GnuPG signature!
Removing autoconf_2.58-9_i386.changes, but keeping its associated files for now.

Greetings,

Your Debian queue daemon
--

I didn't understand that message--this is the same key I've
always used for Debian uploads; I haven't seen it on any lists of
keys removed from the keyring, its fingerprint shows up in my
entry on db.debian.org, and it appears to be still available from
keyring.debian.org.

After that, I've received over 134 copies of the following
message:

--
Subject: Incomplete upload found in Debian upload queue

Probably you are the uploader of the following file(s) in
the Debian upload queue directory:
  autoconf_2.58-9.diff.gz
  autoconf_2.58-9.dsc
  autoconf_2.58-9_all.deb
This looks like an upload, but a .changes file is missing, so the job
cannot be processed.

If no .changes file arrives within 22:59:37, the files will be deleted.

If you didn't upload those files, please just ignore this message.

Greetings,

Your Debian queue daemon
--

Isn't that a bit excessive?  How do I make this stop?  And why
was my upload rejected?
-- 
"If a person keeps faithfully busy each hour of the working day, he
 can count on waking up some morning to find himself one of the
 competent ones of his generation."
--William James

Building Debian Completely From Source

[John Goerzen]

Hello,

For various reasons [1], I am interested in building Debian from source
-- and continuing to do so for upgrades and newly-installed packages.

What I'm after is basically something where I can say:

  apt-foo install kde

The system will then:

 1. Look at kde and build/install any of its build-deps
 2. Build kde
 3. Build/install any Depends or Pre-Depends of kde
 4. Install kde

(These four steps would be repeated for all dependencies that had to be
filled.)

In other words, at no time would a .deb be downloaded.  All .debs would
be built locally and installed locally.

I'd also like to be able to say:

  apt-foo dist-upgrade

Which would essentially run the above steps and upgrade my system.
Again, no .deb would ever be downloaded; they'd be built and installed
locally.

We seem to already have the metadata necessary to do this, but as far as
I can tell, our existing tools don't support it.  For instance:

 * apt-build has an option to build a package and all packages it
   depends upon, but always downloads binary .debs of -dev packages.
   (Or maybe I got this backwards; I'm not sitting at my apt-build
   machine right now.)

 * pbuilder and sbuild don't bother with actual installation,
   so they don't resolve dependencies at all.  Also, they only download
   .debs of build-deps.

The nearest I have seen is fink, but I know little about it.

Am I missing something?  Is anyone working on this?

Thanks,

John

[1] I want to experiment with different optimizations on the Alpha...
plus this would significantly reduce the number of CD's I'd have to
carry around to have a whole Debian release with me.  One binary CD for
each arch, plus a source CD set that would work for them all.

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

[Henning Makholm]

Scripsit Joey Hess <[EMAIL PROTECTED]>
> Mathieu Roy wrote:

> > It doesn't need to be done in two days, does it? If new packages start
> > directly with .desktop and others packages move to .desktop in the
> > next year, it does not seems to be an awful load of extra work.

> If that happened then we would, for an undefined length of time that
> would probably span a Debian release, have two divergent sets of menus,
> with some programs randomly on the Debian menus, and some programs
> randomly on the free desktop menus. This would be unusable, and a
> bad regression.

Evidently, so that's not what is proposed. The proposal is to enhance
update-menus such that it knows how to parse .desktop files and feed
the information from them transparently to menu methods that expect
the Debian native format. Then debian-native menu systems would give
the same user experience independently of which packages had
transitioned to the .desktop format.

Packages that uses the .desktop format natively already have
maintainer scripts that know how to translate debianized menu entries
into that. They may need some cooperation from update-menus in order
to not show two entries for things that have .desktop entries of their
own, but that is also minor.

> You speak of a transition, but I see no transition plan here.

What do you expect from a "transition plan" then?

  Step 1a: Update menu infrastructure such that packages can transparently
 supply either .desktop files or Debian menu files.

  Step 1b: At the same time, update menu infrastructure such that WM
packages providing menu methods can opt to receive package data in
.desktop format (autotranslated from Debian menu files if necessary).

  Step 2: Packagers can now chose to supply .desktop files instead of
 the Debian format, with a versioned dependency on menu.

  Step 3: After a stable version with the updated infrastructure has
 been released, the Debian menufile format can be deprecated
 (should not happen before, because it would make backports
 harder).

  Step 4: When all (or most) menu methods have been converted to
 reading .desktop files, policy can be amended along the lines of
 "*must* provide a .desktop file rather than the old
 Debian-specific menu format".

  Stem 5: Compatibility code for the old format in the menu
 infrastructure will be kept until it gets too much of a burden
 to maintain it.

-- 
Henning Makholm"What the hedgehog sang is not evidence."

Re: debian pxe dhcp netinstall (debconf enterprise fai etc.)

[Henning Glawe]

On Fri, Dec 05, 2003 at 01:13:57AM -0800, Mark Ferlatte wrote:
> FAI is good, but it doesn't handle updating the systems once you have them
> installed.
with a few modifications you can do this...
i did a fork of FAI 2.3, which is used in my department for
installations and updates. much of my work is already merged into FAI. 
currently I'm porting the rest of my changes to HEAD, so they can be
merged...
the problem is, as in many cases, the lack of documentation...

-- 
c u
henning

Re: Building Debian Completely From Source

[John Goerzen]

On Fri, Dec 05, 2003 at 03:02:29PM -0500, Matt Zimmerman wrote:
> On Fri, Dec 05, 2003 at 01:53:11PM -0600, John Goerzen wrote:
> 
> > The nearest I have seen is fink, but I know little about it.
> > 
> > Am I missing something?
> 
> apt-src, apparently.

Well, not really.  apt-src doesn't integrate with apt/dpkg very much.
For instance, apt-src --build upgrade doesn't upgrade every package
that's out-of-date on your system vs. what's available.  Rather, it
upgrades all the sources in your apt-src build directory.  So if you
delete some to save space, you're screwed.  Plus you lose apt features
like pinning.

Moreover, it also doesn't seem to support building of depends and
build-deps, but I didn't personally verify that.

-- John