Ok, so sarge has been released! We should all thank the Release Team for
their hard work in putting this major release together. But... how about we
start discussing about what major release goals we want to set for Etch? 

So, without further delay, here's my "Etch-wishlist", it's biased on some
of the things I've personally worked on and would like to keep working on
for etch. I would love to hear the Release Managers opinion on what they 
believe should be Release Goals for etch besides the things we all already 
know about (non-free documentation purged from main, changes in supported 
architectures...)

Feel free to add some new items or add (hopefully new) information to the 
ones I list below:

--------------------------------------------------------------------------
[ Overall improvements ]
- _No_ bugs in base packages (well, at least no old bugs). Base system
should be upgraded to latest upstream (forward patches!) this includes
PAM, modutils...
* Base packages should be co-maintained and maintainers should be
open to help (not always the case currently)
See  http://bugs.qa.debian.org/base-full.html
(Personal note: packages in base packages older than a year should either
be closed or handled properly, i.e. fixed)

[ Installation improvements ] 
- Firewall configuration during installation (ala Fedora Core or SuSE):
module for d-i. Currently, the system is exposed just during installation
on some systems (empty root password?)
- Reduced standard installation (no gcc or development tools!, see 
#301138 or #301273)
- More "tasks" (grouped packages) for installation: automatic detection
of user needs and automatic task selection?

[ Security improvements ] 
- Proper package signature checks (apt-secure, currently on experimental)
- Buffer overflow protection: ExecShield or PaX in stock kernel
- Mandatory Access Control support: SELinux support (RSBAC?)
- Possibility to recompile the distro with SPP (apt-build?). New
i386-spp architecture?
- Proper source code audit by maintainers to detect stupid security
bugs (/tmp/XX.?? anyone?) Recurrent things like #306893 appear all
too often. Automatic source code audit ala lintian.debian.org? 
- MD5 / SHA-1 listing of files in ftp sites (useful for forensics analysis
see #303961)

[ Admin improvements ]
- Possibility to startup the OS in "control" mode: select which init 
scripts  will run, this provides a way to work-around hardware issues after
d-i has installed the base system (personal example: #301112)
- 'Status' in init.d scripts (#291148)
- hardware changes detection: system detects after a reboot when
a new SVGA card, new Ethernet card, etc. has been installed and prompts
for new confguration.
- inetd begone! -> xinetd (better mechanism to control DoS, privilege
separation, etc.)
- Checksecurity -> live up to its name and merge changes from other distros
and BSDs
- Security / Update managements of multiple servers from a single point.
There's no single tool to do check the security status of many servers
at once (like done in RedHat's Network). Use OVAL agents?
See #253097
- Better OS backup management  -> upgrade rollback?
- Alternate bootup mechanism (dependancy based? see Solaris 10 or 
http://www.atnf.csiro.au/people/rgo...x/boot-scripts/)
- Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=5
- Using dpkg as an audit tool to detect changes in the system, not as 
a security mechanism but to detect broken stuff (includes #155799 and #34194
)

[ End user improvements ] 
- Better help/documentation search (dwww sucks, dhelp needs improvement)
Provide a "Debian documentation center" with search functions to
detect information in READMEs, html files, manuals relevant to a 
free-text query?
- Proper User/Sysadmin documentation guides (similar to what RedHat or
SuSE already provide, not FAQs or HOWTOs)
- I18n documentaion in CD-ROMs, better track of out-of-date translations
- Better package search mechanism (tags?) allowing free text search
in package management interfaces: "I want a program that does X"

[ Release improvements ] 
- Prune packages from release based on popularity, packages which are not
used by anyone should not go in! (not enough peer review, probably
not audited, bug ridden with bugs, including security making security
handling a nightmare)
- Remove _all_ out of date dummy packages! (see #308711 and other bugs!)
- Better (not manual!) tracking of bugs associated with testing release
--------------------------------------------------------------------------

Regards

Javier

[ Post a follow-up to this message ]

On Jun 07, Javier Fernández-Sanguino Peña <jfs@computer.org> wrote:

> - _No_ bugs in base packages (well, at least no old bugs). Base system
>   should be upgraded to latest upstream (forward patches!) this includes
>   PAM, modutils...
In my wishlist there is NO support of 2.4 kernels, so modutils would
become unneeded.
2.4.x kernels are already obsolete by now except that for some doorstop
architectures, I do not know about any other modern distribution which
still installs one.

> - inetd begone! -> xinetd (better mechanism to control DoS, privilege
>   separation, etc.)
What about you try a decent inetd instead?
Anyway, I have in my wishlist being able to easily switch *inetd
daemons.

-- 
ciao,
Marco

[ Post a follow-up to this message ]

Javier Fernández-Sanguino Peña wrote:
> [ Installation improvements ] 
> - Firewall configuration during installation (ala Fedora Core or SuSE):
>   module for d-i. Currently, the system is exposed just during installatio
n
>   on some systems (empty root password?)

This has not really been discussed on debian-boot, but one of my
personal goals for a d-i improvement for etch is that the whole system
installation takes place in d-i, there is no separate base-config stage
and you boot straight from d-i into your installed desktop system (or
whatever).

This solves your problem fairly well, since the issue then becomes only
keeping d-i secure and keeping the installed system secure, not keeping
the system secure while it's installing itself. Daemons will not be
started dueing the installation, and will come up on reboot.

Some kind of firewall task would probably complete what you're looking
for here, so the installed system boots up with a complete firewall in
place.

> - Reduced standard installation (no gcc or development tools!, see 
>   #301138 or #301273)

Absolutely going to happen, but probably not in the the way most
commonly mentioned in these bug reports. I will acept patches to tasksel
that make it offer a "Standard system" task, that is selected by default
and can be de-selected. If noone sends patches, I'll get around to it
eventually, I suppose.

> - More "tasks" (grouped packages) for installation: automatic detection
>   of user needs and automatic task selection?

Planned, and ground already laid in tasksel (and indeed, it does do it
for some easy things like language tasks). One thing I really want to
see happen is a laptop task. The big missing peice is some simple
program tasksel can call out to, like

if this_is_a_laptop; then
.
fi

This should use whatever hardware probing works best for laptops.

I'm interested in other ideas for automatic selection of default tasks.

> - hardware changes detection: system detects after a reboot when
>   a new SVGA card, new Ethernet card, etc. has been installed and prompts
>   for new confguration.

As long as this is in a package that can be purged and/or argued over
heatedly about whether it should be installed by default. :-) In other
words, not wanted on any machine I touch.

-- 
see shy jo

[ Post a follow-up to this message ]

On Tue, 2005-07-06 at 01:03 +0200, Javier Fern=E1ndez-Sanguino Pe=F1a wrote=
:
> [ Installation improvements ]=20
> - Firewall configuration during installation (ala Fedora Core or SuSE):
>   module for d-i. Currently, the system is exposed just during installati=
on
>   on some systems (empty root password?)

Right.  Especially for workstation installation something like below
would allow to connect from workstation to anywhere else, but not to
any servers ran on workstation.

# Already existing connections are allowed (incoming&related icmp too)
-A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT
-A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
# all outgoing traffic is allowed
-A OUTPUT -p tcp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p udp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

My impression was that firewall setting is generally a messy business,
because there's too many packages that mess with it, usually assuming
they're the only ones who touch it.  This was, I think part of the
reason why /etc/init.d/iptables was removed (I still use it on all of
my old and newly installed machines, btw.)  But maybe I am wrong and
somebody else could provides more details here.

> - 'Status' in init.d scripts (#291148)

...and 'zap'.  Altough it's a solution from 'should never be needed'
dept. ask yourself how many times you had to killall -9 $something.
(not that killall is the right solution for zap!)

> - inetd begone! -> xinetd (better mechanism to control DoS, privilege
>   separation, etc.)

IIRC a mechanism for *netd switching had been discussed in Woody times,
then waited for Sarge and I believe we already had some preliminary
implementation but it's still not finished.  Other distros like PLD had
that years ago, btw.

> - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=
=3D5

Do we really need that?  I thought I could always
enable/disable/install/remove [xgk]dm.  And are these runlevels mandated
(or at least documented) by any standard (besides 'the RH way')?  Are
they at least consistent among ~"all distros besides Debian"?

> - Better package search mechanism (tags?) allowing free text search
>   in package management interfaces: "I want a program that does X"

Doesn't 'apt-cache search X' do exactly that?

Cheers,

Grzegorz B. Prokopski
--=20
Grzegorz B. Prokopski           <gadek@sablevm.org>
SableVM - Free, LGPL'ed Java VM  http://sablevm.org
Why SableVM ?!?                  http://sablevm.org/wiki/Features
Debian GNU/Linux - the Free OS   http://www.debian.org

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

On Tuesday 07 June 2005 08:56, Frans Pop wrote:
> On Tuesday 07 June 2005 03:21, Joey Hess wrote: 
Another item that might be worth considering for laptops is a networking
equivalent of the pmount group.  People in these groups would be allowed
to edit the network files (in particular /etc/network/interfaces) and bring
interfaces up and down.  Obviously on servers and corporate desktops
this group would be empty or contain only system admins, but on a
laptop you have to be able to fit into the network you are presented
with and you do not want joe-user to be switching to root all the time
just in order to do these functions.

I realise that this would require fixes to a number of packages, and quite
possibly some additional code to give a graphical interface to the
/etc/networking/interfaces file would be a good idea for GUI only users
and those who might not understand the consequences of incorrectly
coded entries and need a program to do it for them.

David[vbcol=seagreen]
>
> This sounds like a good idea, but will need very careful logic.
> For instance, some older (APM-based) Toshiba laptops work well with the
> toshiba module and the toshset package where newer (ACPI-based) laptops
> need the toshiba-acpi module which does not work with toshset.
> I would suspect that similar distinctions exist for other makes.
> 
>
> One thing I feel is currently missing is to show users which tasks have
> been automatically selected and the option to deselect them (maybe only
> at medium or lower priority).
>
> Which brings me to another pet wish: make it a lot easier to install at
> medium priority than currently.
> IMO there is a real use for medium priority:
> - experienced users now often choose expert and get confused by some of
>   the informational dialogs (especially the "unavailable drivers" one)
> - for users installing for the first time the "no dhcp" boot option and
>   such are not really obvious, medium priority can be used to offer
>   useful freedom in a structured way keeping expert for difficult hardware


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

On 2005-06-07 04:57, Grzegorz B. Prokopski wrote:
> On Tue, 2005-07-06 at 01:03 +0200, Javier Fern=E1ndez-Sanguino Pe=F1a wro=
te: 
>
> Do we really need that?  I thought I could always
> enable/disable/install/remove [xgk]dm.  And are these runlevels mandat
ed
> (or at least documented) by any standard (besides 'the RH way')?  Are
> they at least consistent among ~"all distros besides Debian"?

If we're gonna change this, could we please use the LSB definition [1]?

[1]=20
http://refspecs.freestandards.org/L...LSB-Core-gener=
ic/runlevels.html
=2D-=20
Cheers, cobaco (aka Bart Cornelis)
=20
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)

[ Post a follow-up to this message ]

On Tue, Jun 07, 2005 at 01:47:12AM +0200, Marco d'Itri wrote:
> On Jun 07, Javier Fernández-Sanguino Peña <jfs@computer.org> wrote:
> 
> In my wishlist there is NO support of 2.4 kernels, so modutils would
> become unneeded.
> 2.4.x kernels are already obsolete by now except that for some doorstop
> architectures, I do not know about any other modern distribution which
> still installs one.

Since (at least) potato, Debian has always supported more than one major
line of kernels. I don't see why we suddenly would need to change that
now.

I _do_ agree, however, that 2.2 should be dropped. This might mean
having to drop the mac subarch for m68k if the kernel isn't fixed by the
time etch releases, but then so be it.

--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

On Tue, Jun 07, 2005 at 11:12:50AM +0200, Wouter Verhelst wrote:
> On Tue, Jun 07, 2005 at 01:47:12AM +0200, Marco d'Itri wrote: 
[vbcol=seagreen]
> Since (at least) potato, Debian has always supported more than one major
> line of kernels. I don't see why we suddenly would need to change that
> now.

We've done this out of necessity -- *not* because it's a good idea.

-- 
Steve Langasek
postmodern programmer

[ Post a follow-up to this message ]