Hi

On Fri, Apr 21, 2006 at 07:35:01PM +0200, Thomas Huriaux wrote:
> Ola Lundqvist <[EMAIL PROTECTED]> (21/04/2006):
> > On Fri, Apr 21, 2006 at 12:14:01PM +0200, Thomas Huriaux wrote:
> > > But if your package does nothing else than providing help to the
> > > administrator, why don't you create a simple binary to display these
> > > instructions? I still don't understand the reason to display these
> > > instructions during the installation process, at it does not change
> > > anything for the package usability.
> > 
> > Why should I create a binary when I can just write it in a documentation.
> 
> My idea with a binary was to remove the conflicts, and to let the user
> choose what to be removed or not by launching this binary. For example:
> 
>   test if servers with plaintext passwords are installed
>   if true
>     display harden-servers/plaintext
>     prompt the user to remove the incriminated package
>     if yes
>       removal of the incriminated package
> 
> But that would change the philosophy of the package.

Hmm. Maybe the plaintext description is not very clear... What I want to
tell in them are that even if a package support encryption you need
to really make use of it. That is why they are displayed.

> > The usefulness of this package is that the admin will know about
> > this _during_ the installation.
> > 
> > I still do not understand why you have a problem with this.
> 
> Because installation is not the place to care about this. As I've said,
> the purpose of a package should be documented on places such as package
> description, project website, ..., the use of a package should be
> documented in manpages, README files, etc. Keep the things where they
> belong.

But this package is intended for people that are not that used to Debian
and security hardening. They probably do not even know about the README.Debian
files anyway.

> Just imagine that every package displays debconf notes such as your
> package does (i.e. notes that are not related with the package
> configuration). I really think that Debian would be unconfigurable, as
> every package would stop the installation procedure many times
> (especially true for harden/welcome, even if it is also true for the
> other notes).

I agree in general but I still think that these notes are valid to print.

> Another problem that I see with this: during the installation procedure,
> I usually only want to configure the newly installed packages. In this
> case, I'm installing the harden suite and plenty of other packages. As
> I've seen that the Debconf notes were not related with the configuration,
> I just read them but took no action immediatly, as it is better to finish
> the full installation before reconfiguring other packages. Now that my
> installation is finished, I want to make my system secure.
> I don't think that dpkg-reconfigure harden-servers is the intuitive
> way to find the instructions (this is especially true for the
> harden-servers/vncserver and harden-servers/inetd notes).

We can of course add the notes to the README.Debian file as well as the
debconf output.

> Finally, I would accept some notes being displayed during the installation
> procedure, but only before being prompted by apt/aptitude if I accept to
> remove packages that conflict with harden* (in the case of
> harden-servers/plaintext and harden-clients/plaintext). This is
> unfortunately not possible, AFAIK. With the current conception of the
> package, these notes are displayed too late to be useful during the
> installation procedure.

What? The notes are not for you to remove packages but to make sure that
you use try to configure your system for encryption.

> Conclusion: If you want to keep the current philosophy of the package
> without bothering users with pointless notes, you should take the
> following actions:
> * remove harden/welcome (or move it to a README.Debian file)
It is already with priority low output, so I do not really agree.

> * remove harden-*/plaintext and emphasize (if needed) the package
>   description about the conflicts
But they are not for describing the conflicts.

> * provide documentations such as README, manpage, ... for
>   harden-servers/inetd and harden-servers/vncserver (and of course
>   remove those notes)

No I will not do this last point, unless inetd have changed their
defaults of course.

Regards,

// Ola

> Cheers,
> 
> -- 
> Thomas Huriaux



-- 
 --------------------- Ola Lundqvist ---------------------------
/  [EMAIL PROTECTED]                     Annebergsslingan 37      \
|  [EMAIL PROTECTED]                 654 65 KARLSTAD          |
|  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to