Re: DEBIAN SOCIOLOGICAL STUDY.

[Martin Michlmayr]

* Kevin Mark <[EMAIL PROTECTED]> [2005-07-01 23:34]:
> > and we are doing a sociological survey on Debian in order to
> > better understand the Debian community.
>
> didn't tbm do some research into this?

Yes and no.  There is currently a lot of interest in free software and
various researchers study it from their perspectives, e.g. sociology,
management, economics, software engineering, etc

While my research is about free software, it doesn't seem to be
related to this survey at all.  My own research is generally about
quality assurance and improvement and specifically about release
management as one aspect of quality management.  See
http://www.cyrius.com/research/ for some more details.

For people who're interested to find out what has been published,
http://opensource.mit.edu/ has a fairly large collection of papers and
the proceedings of the workshop on open source engineering are
available at http://opensource.ucc.ie/

Some researchers are quite new to free software and are only starting
to understand how everything works, but others do good work - work
from which the community can benefit.
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Libtool and packaging

[Junichi Uekawa]

Hi,

> 
> If someone has some info on this, do respond...

If you do show what kind of source you are referring to, it 
might help.



regards,
junichi

-- 
Junichi Uekawa, Debian Developer   http://www.netfort.gr.jp/~dancer/
183A 70FC 4732 1B87 57A5  CE82 D837 7D4E E81E 55C1 


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

HashKnownHosts

[Marco d'Itri]

What is the rationale for changing the default setting?
I find it very annoying, and from a brief discussion on #debian-devel I
see that I'm not alone.


(BTW, would you mind fixing #284874? It's six months old and should be
trivial...)

-- 
ciao,
Marco


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

Re: HashKnownHosts

[Olaf van der Spek]

On 7/2/05, Marco d'Itri <[EMAIL PROTECTED]> wrote:
> What is the rationale for changing the default setting?
> I find it very annoying, and from a brief discussion on #debian-devel I
> see that I'm not alone.

I guess it went from off to on?
Wasn't there an issue with worms using the known hosts file to spread
further once one system containing private keys had been compromised?

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Andrew Suffield]

On Thu, Jun 30, 2005 at 09:43:04PM +0100, Gervase Markham wrote:
> >Why can't we leave this to the maintainer or even local admins though?
> 
> These are two very different cases, though. If a local admin installs a 
> new root cert, that's cool - they are taking responsibility for the 
> security of those users, and they have extreme BOFH power over them 
> anyway. However, having the root appear by default, so that no-one at 
> the remote site really knows it's there (who consults the root list) and 
> it's now on Y thousand or million desktops - that is a different kettle 
> of fish.

You've missed the really interesting, really important case.

What about the site admin team for X thousand desktops who produce a
modified firefox package to be used across the whole company? This is
the normal, expected usage of Debian.

> A quick reminder of what's at risk here: if the private key of a root 
> cert trusted by Firefox became compromised, _any_ SSL transaction that 
> any user trusting that cert performed could be silently MITMed and 
> eavesdropped on.

Let's be serious here. You've already got the verisign certificates,
and you've got a helpful dialog box that appears whenever new
certificates are presented to the browser such that the user can just
whack 'ok' without reading it. SSL security on the internet at large
is a myth. Anybody who trusts it is insane; the risks aren't very
significant.

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


signature.asc
Description: Digital signature

cpufrequtils init script in rcS.d

[Mattia Dongili]

Hello *,

in closing #311604 I'm adding an init script to the package along with
its /etc/default entry to set a default governor on boot.
Anyway while reasoning on the script start order number I realized that
it might be good to have it into rcS.d instead of the default choice.
cpufreq-set only needs sysfs mounted so adding 'start 37 S .' seems
appropriate.
As per policy 9.3.3.1 (even if I already have a pretty clear idea on
what to do) I'm asking here for suggestions or your blessing. :)

The rationale around my choice is that:
- the kernel allows setting a default governor at compile time but that
  might not be what the users want by default (expecially kernel-image*
  users)
- the ondemand/conservative governors (the most useful actually) cannot
  be set as defaults in Kconfig as they are known not to work for every
  processor (transition latency issues)
- setting the CPUFreq policy must be done as early as possible in the
  boot process (IMHO)
So the choice of rcS.d seems to be the only good solution.

In the package I have already available here the init script is inactive
by default (I'm considering putting some debconf magic to let the user
choose the governor instead) so this rcS script is very low impact right
now.

Thanks for your time and any suggestion.
-- 
mattia
:wq!


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

Re: HashKnownHosts

[Florian Weimer]

* Marco d'Itri:

> What is the rationale for changing the default setting?

Reducing wormability.  I think it's a pretty clever change.


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

New gimp-print packages in experimental

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi folks,

gimp-print (renamed to gutenprint) is near its 5.0 release.  I've
uploaded a prerelease to experimental, which is also available here:

http://people.debian.org/~rleigh/gutenprint/experimental/4.3.99+cvs20050702-1/

It integrates with a number of other packages, and so I would be
grateful if the respective maintainers could test it before it enters
unstable.  General upgrade testing would also be appreciated.

- - cupsys, tested with an Epson Stylus C60
- - ijsgutenprint, tested with an Epson Stylus C60
- - foomatic data needs testing
- - gs-esp and gs-gpl need to remove the STP patch, which is no longer
  supported.  Once gutenprint enters unstable, they will no longer
  build from source otherwise.
- - gimp (gimp-print) needs testing after the current FTBFS bug has been
  fixed (#316538).
- - cinepaint needs updating to use and build depend upon
  libgutenprintui-dev.
- - apsfilterconfig can no longer provide the stp driver
"4)  gimp-print (stp driver [DEPRECATED - use ijs]; version 4.2.x)"
  which will be removed from gs.

In addition to these specific packages, any other packages which
depend indirectly on libgimpprint, ijsgimpprint, the foomatic data or
other gimp-print features should be converted and tested to work with
5.0.0.

I would be very grateful for anyone who has time to build and install
the packages, and report any upgrade failures.  Any regressions in
print quality, colour reproduction, usability, integration with other
packages etc. will also be very helpful.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCxqOQVcFcaSW/uEgRArK7AKDnk1tHHJsmAa9aHAoDd8PRK//xwgCfcy+T
ZcSuPTycXKkJbpEk4jqQra0=
=fqQH
-END PGP SIGNATURE-


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

Re: HashKnownHosts

[Marco d'Itri]

On Jul 02, Florian Weimer <[EMAIL PROTECTED]> wrote:

> > What is the rationale for changing the default setting?
> Reducing wormability.  I think it's a pretty clever change.
This is not what I asked, I know what this option is for.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: HashKnownHosts

[Olaf van der Spek]

On 7/2/05, Marco d'Itri <[EMAIL PROTECTED]> wrote:
> What is the rationale for changing the default setting?
> I find it very annoying, and from a brief discussion on #debian-devel I
> see that I'm not alone.

What causes this annoyance?

Re: HashKnownHosts

[Wouter Verhelst]

On Sat, Jul 02, 2005 at 03:05:47PM +0200, Florian Weimer wrote:
> * Marco d'Itri:
> 
> > What is the rationale for changing the default setting?
> 
> Reducing wormability.  I think it's a pretty clever change.

Some of us actually do care what is listed in that file, and edit it
from time to time. Hashing those names makes that much harder -- and
relying on other people's security to increase your own isn't pretty
clever, actually.

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


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

Re: HashKnownHosts

[Marco d'Itri]

On Jul 02, Olaf van der Spek <[EMAIL PROTECTED]> wrote:

> On 7/2/05, Marco d'Itri <[EMAIL PROTECTED]> wrote:
> > What is the rationale for changing the default setting?
> > I find it very annoying, and from a brief discussion on #debian-devel I
> > see that I'm not alone.
> What causes this annoyance?
The need to edit the file to add/update/remove IP addresses, hostnames
and whole keys.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: HashKnownHosts

[Olaf van der Spek]

On 7/2/05, Marco d'Itri <[EMAIL PROTECTED]> wrote:
> On Jul 02, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> 
> > On 7/2/05, Marco d'Itri <[EMAIL PROTECTED]> wrote:
> > > What is the rationale for changing the default setting?
> > > I find it very annoying, and from a brief discussion on #debian-devel I
> > > see that I'm not alone.
> > What causes this annoyance?
> The need to edit the file to add/update/remove IP addresses, hostnames
> and whole keys.

What prevents you from turning the option off again?
And do you think more people need it off then on?

Re: HashKnownHosts

[Florian Weimer]

* Marco d'Itri:

> On Jul 02, Florian Weimer <[EMAIL PROTECTED]> wrote:
>
>> > What is the rationale for changing the default setting?
>> Reducing wormability.  I think it's a pretty clever change.
> This is not what I asked, I know what this option is for.

Given it's purpose, this option doesn't make that much sense if it's
not enabled by default.

(Actually, I hope it's not just Microsoft who sometimes piss off their
users if security-related changes require it.  Otherwise, Microsoft
will easily win the security wars even before they are declared.)


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

Re: HashKnownHosts

[Florian Weimer]

* Wouter Verhelst:

> Some of us actually do care what is listed in that file, and edit it
> from time to time. Hashing those names makes that much harder

There should be tools supporting this, I agree.

> -- and relying on other people's security to increase your own isn't
> pretty clever, actually.

Currently, it's the foundation of Internet security, I'm afraid.


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

X.Org transition and xlibs-static-* issues

[David Nusinow]

Hi everyone,
   We're in preparation to upload X.Org packages to unstable, and one of
the things which will happen in this transition is a change in the way
xlibs-static-* packages are handled. If your package build-depends on
xlibs-static, you'll have to update your build-depends to deal with the
transition. A list of packages that I am aware of which build-depend on
xlibs-static-* is below, sorted by maintainer. If your package is on this
list, or if I missed you, you may want to check the collection of available
Ubuntu patches for your package[0] to see if your problem has already been
solved.

   If your package is not already patched by Ubuntu, then you'll have to
make the transition yourself. A table has been made that maps header files
to new library packages[1], so you need to figure out which headers your
app uses and then add that library to your Build-Depends.

   Another item of note is that Xinerama support can currently be silently
disabled by the build system if Xinerama.h is absent. Please be sure to
pass --enable-xinerama in your builds if you use Xinerama, in order to be
sure that this doesn't happen to you, as it will then fail if Xineram a.h is
absent.

   For those of you who want to test your package builds against the new
system, there are packages for x86 built and available, or you can pu ll and
build yourself. The Ubuntu X.Org packages, if you're running them, also
have this change, so you can continue to use them for testing your packages
if you prefer.

 - David Nusinow

[0] http://people.ubuntu.com/~scott/patches/
[1] http://people.ubuntu.com/~daniels/xlibs-static-dev.txt
[2] Add "deb http://people.debian.org/~dnusinow/xorg ./" to your
sources.list. The sources are also available in this archive if you
want to build for a different arch.

--

Maintainer: Akira TAGOH <[EMAIL PROTECTED]>
Package: at-spi
Package: gok

Maintainer: Arnaud Patard <[EMAIL PROTECTED]>
Package: control-center

Maintainer: C=E9dric Delfosse <[EMAIL PROTECTED]>
Package: gl-117
Package: iris

Maintainer: Debian OpenOffice Team 
Package: openoffice.org

Maintainer: Debian Qt/KDE Maintainers 
Package: arts
Package: kdebase
Package: kdegraphics
Package: kdemultimedia
Package: kdenetwork

Maintainer: Debian Xfce Maintainers <[EMAIL PROTECTED]>
Package: libxfce4mcs
Package: libxfcegui4
Package: xfce-mcs-manager
Package: xfce4-appfinder
Package: xfce4-iconbox
Package: xfce4-utils

Maintainer: Filip Van Raemdonck <[EMAIL PROTECTED]>
Package: clanlib
Package: gswitchit
Package: libxklavier

Maintainer: Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]>
Package: gem

Maintainer: Guillem Jover <[EMAIL PROTECTED]>
Package: xfstt

Maintainer: Gustavo Noronha Silva <[EMAIL PROTECTED]>
Package: gvidm

Maintainer: Jamie Wilkinson <[EMAIL PROTECTED]>
Package: freeglut

Maintainer: John Lightsey <[EMAIL PROTECTED]>
Package: xmms-jess

Maintainer: Josselin Mouette <[EMAIL PROTECTED]>
Package: wmcoincoin

Maintainer: Laurence J. Lane <[EMAIL PROTECTED]>
Package: enlightenment

Maintainer: Ludovic Brenta <[EMAIL PROTECTED]>
Package: libadabindx

Maintainer: Marc Dequ=E8nes (Duck) <[EMAIL PROTECTED]>
Package: gnome-applets

Maintainer: Mario Lang <[EMAIL PROTECTED]>
Package: gnopernicus

Maintainer: Martin Albert <[EMAIL PROTECTED]>
Package: libggi

Maintainer: Martin Loschwitz <[EMAIL PROTECTED]>
Package: qt-x11-free

Maintainer: Masahito Omote <[EMAIL PROTECTED]>
Package: uim

Maintainer: Miriam Ruiz <[EMAIL PROTECTED]>
Package: kball
Package: kraptor

Maintainer: Moray Allan <[EMAIL PROTECTED]>
Package: xrestop

Maintainer: Philipp Matthias Hahn <[EMAIL PROTECTED]>
Package: xosd

Maintainer: Randall Donald <[EMAIL PROTECTED]>
Package: nvidia-settings

Maintainer: Ross Burton <[EMAIL PROTECTED]>
Package: gossip

Maintainer: Russ Allbery <[EMAIL PROTECTED]>
Package: gtimer

Maintainer: Ryan Murray <[EMAIL PROTECTED]>
Package: gdm
Package: gqview

Maintainer: Sam Hocevar (Debian packages) <[EMAIL PROTECTED]>
Package: allegro4
Package: allegro4.1
Package: kxl
Package: powermanga
Package: vlc

Maintainer: Sebastien Bacher <[EMAIL PROTECTED]>
Package: gtk+2.0
Package: lock-keys-applet

Maintainer: Siggi Langauf <[EMAIL PROTECTED]>
Package: xine-lib

Maintainer: Steinar H. Gunderson <[EMAIL PROTECTED]>
Package: amoeba

Maintainer: Steve McIntyre <[EMAIL PROTECTED]>
Package: nas

Maintainer: The ROX-in-Debian Project Team <[EMAIL PROTECTED]>
Package: rox


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

Re: HashKnownHosts

[Wouter Verhelst]

On Sat, Jul 02, 2005 at 09:04:18PM +0200, Florian Weimer wrote:
> * Wouter Verhelst:
> 
> > Some of us actually do care what is listed in that file, and edit it
> > from time to time. Hashing those names makes that much harder
> 
> There should be tools supporting this, I agree.

There are tools supporting a default configuration without that crap
enabled -- text editors.

> > -- and relying on other people's security to increase your own isn't
> > pretty clever, actually.
> 
> Currently, it's the foundation of Internet security, I'm afraid.

Well, then the 'foundation of Internet security' is very weak, I'm
afraid. It's plain stupid to rely on someone else to get _your_ security
working correctly. Think about it.

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


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

Re: HashKnownHosts

[Olaf van der Spek]

On 7/2/05, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > > -- and relying on other people's security to increase your own isn't
> > > pretty clever, actually.
> >
> > Currently, it's the foundation of Internet security, I'm afraid.
> 
> Well, then the 'foundation of Internet security' is very weak, I'm
> afraid. It's plain stupid to rely on someone else to get _your_ security
> working correctly. Think about it.

Did you check and compile the source code of every package you're
running yourself?

Re: HashKnownHosts

[Marco d'Itri]

On Jul 02, Wouter Verhelst <[EMAIL PROTECTED]> wrote:

> Well, then the 'foundation of Internet security' is very weak, I'm
> afraid. It's plain stupid to rely on someone else to get _your_ security
> working correctly. Think about it.
There is also the quite important point that even the most stupid of the
attackers could just look at ~/.bash_profile instead and get all or most
of the hostnames anyway, so I still do not see the benefits of enabling
this option by default.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Gervase Markham]

Lionel Elie Mamane wrote:

On Thu, Jun 30, 2005 at 09:43:04PM +0100, Gervase Markham wrote:

Because we can't do it using a copyright licence? ;-P


Perhaps I shouldn't have made that flippant comment.


What do you mean you can't? You most certainly can, "just" rewrite the
license to say that redistribution of modified versions is permitted
only it passes QA. 


You realise, I am sure, that this "just" would a) require getting the 
permission of probably close to 1000 people, almost all of whom are 
advocates of free software, and b) not being free software any more. But 
I'm sure it wasn't a serious suggestion anyway, so let's not consider it 
any more.



The impression you are making here is "Hey, we want to enforce some
limitation, but if we do it through copyright license, we will put
ourselves out of the free software community. So we backdoor the very
same limitation through trademark law in the hope that the free
software community will be confused enough to still count us as a
member, and accept our trojan horse."


Actually, there are free software copyright licences which require a 
name change of you make code modifications (e.g. Apache v1). I think 
that means that restrictions on names and branding, assuming they don't 
present practical difficulties, are certainly not incompatible with free 
software.


Gerv



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

Re: HashKnownHosts

[Colin Watson]

On Sat, Jul 02, 2005 at 11:19:26AM +0200, Marco d'Itri wrote:
> What is the rationale for changing the default setting?

It's very likely to become the upstream default soon enough; they are
merely waiting on more testing. Since this is unstable, I decided it was
as good a time as any to provide some of that testing, since the feature
seemed solid enough to me.

> I find it very annoying, and from a brief discussion on #debian-devel I
> see that I'm not alone.

I'll need a much better reason than that to be persuaded to disable it
again. While I realise that it's quite a soft security measure and that
all it does is slow down attack vectors somewhat, it does manage that,
and userspace tools to manage known_hosts are now provided (and,
frankly, I'd rather people used those than that they went in and edited
known_hosts by hand anyway; the latter used to cause problems when
people accidentally inserted line breaks or whatever).

> (BTW, would you mind fixing #284874? It's six months old and should be
> trivial...)

Sorry I haven't got round to this yet. The reason I haven't done it is
that it should be added to both /usr/share/doc/openssh-client/ and
/usr/share/doc/openssh-server/, which led me to decide that the
documentation directories should be symlinked together; unfortunately,
when I tried to do this I ran into some complicated upgrade issues that
I couldn't resolve at the time, involving some of the documentation
directories going missing entirely in some cases. I'll give it another
try soon.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: HashKnownHosts

[Colin Watson]

On Sat, Jul 02, 2005 at 09:04:18PM +0200, Florian Weimer wrote:
> * Wouter Verhelst:
> > Some of us actually do care what is listed in that file, and edit it
> > from time to time. Hashing those names makes that much harder
> 
> There should be tools supporting this, I agree.

There is such a tool, which I mentioned in the changelog:

- ssh and ssh-keyscan now support hashing of known_hosts files for
  improved privacy. ssh-keygen has new options for managing known_hosts
  files, which understand hashing.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: HashKnownHosts

[Colin Watson]

On Sat, Jul 02, 2005 at 11:42:40PM +0200, Marco d'Itri wrote:
> On Jul 02, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > Well, then the 'foundation of Internet security' is very weak, I'm
> > afraid. It's plain stupid to rely on someone else to get _your_ security
> > working correctly. Think about it.
> 
> There is also the quite important point that even the most stupid of the
> attackers could just look at ~/.bash_profile instead and get all or most
> of the hostnames anyway, so I still do not see the benefits of enabling
> this option by default.

Firstly, ~/.bash_profile expires regularly; ~/.ssh/known_hosts never
expires. Secondly:

   HISTIGNORE
  A colon-separated list of patterns used to decide  which
  command lines should be saved on the history list.  Each
  pattern is anchored at the beginning  of  the  line  and
  must  match  the  complete  line  (no  implicit  ‘*’  is
  appended).  Each pattern  is  tested  against  the  line
  after  the  checks specified by HISTCONTROL are applied.
  In addition to the normal shell pattern matching charac‐
  ters, ‘&’ matches the previous history line.  ‘&’ may be
  escaped using a  backslash;  the  backslash  is  removed
  before  attempting  a  match.  The second and subsequent
  lines of a multi-line compound command are  not  tested,
  and  are added to the history regardless of the value of
  HISTIGNORE.

In any case, I do not see "information exposed over there" as a reason
in itself why information should be exposed over here, especially when
the exposure over there is much weaker.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: HashKnownHosts

[Colin Watson]

On Sat, Jul 02, 2005 at 11:42:40PM +0200, Marco d'Itri wrote:
> On Jul 02, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > Well, then the 'foundation of Internet security' is very weak, I'm
> > afraid. It's plain stupid to rely on someone else to get _your_ security
> > working correctly. Think about it.
> 
> There is also the quite important point that even the most stupid of the
> attackers could just look at ~/.bash_profile instead and get all or most
> of the hostnames anyway, so I still do not see the benefits of enabling
> this option by default.

Also, this is not true in a world where many desktop users are using GUI
frontends to sftp or the like.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: HashKnownHosts

[Colin Watson]

On Sat, Jul 02, 2005 at 08:17:57PM +0200, Marco d'Itri wrote:
> On Jul 02, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> > On 7/2/05, Marco d'Itri <[EMAIL PROTECTED]> wrote:
> > > What is the rationale for changing the default setting?
> > > I find it very annoying, and from a brief discussion on #debian-devel I
> > > see that I'm not alone.
> > What causes this annoyance?
> 
> The need to edit the file to add/update/remove IP addresses, hostnames
> and whole keys.

Then I'm afraid you simply haven't read the documentation ...

 -F hostname
 Search for the specified hostname in a known_hosts file,
 listing any occurrences found.  This option is useful to
 find hashed host names or addresses and may also be used
 in conjunction with the -H option to print found keys in
 a hashed format.

 -H  Hash a known_hosts file.  This replaces all hostnames and
 addresses with hashed representations within the speci‐
 fied file; the original content is moved to a file with a
 .old suffix.  These hashes may be used normally by ssh
 and sshd, but they do not reveal identifying information
 should the file’s contents be disclosed.  This option
 will not modify existing hashed hostnames and is there‐
 fore safe to use on files that mix hashed and non-hashed
 names.

 -R hostname
 Removes all keys belonging to hostname from a known_hosts
 file.  This option is useful to delete hashed hosts (see
 the -H option above).

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: HashKnownHosts

[Marco d'Itri]

On Jul 03, Colin Watson <[EMAIL PROTECTED]> wrote:

> > The need to edit the file to add/update/remove IP addresses, hostnames
> > and whole keys.
> Then I'm afraid you simply haven't read the documentation ...
I did. But I cannot remove entries if I do not know the hostname.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Michael K. Edwards]

On 7/2/05, Andrew Suffield <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 30, 2005 at 09:43:04PM +0100, Gervase Markham wrote:
> > These are two very different cases, though. If a local admin installs a
> > new root cert, that's cool - they are taking responsibility for the
> > security of those users, and they have extreme BOFH power over them
> > anyway. However, having the root appear by default, so that no-one at
> > the remote site really knows it's there (who consults the root list) and
> > it's now on Y thousand or million desktops - that is a different kettle
> > of fish.
> 
> You've missed the really interesting, really important case.
> 
> What about the site admin team for X thousand desktops who produce a
> modified firefox package to be used across the whole company? This is
> the normal, expected usage of Debian.

Happily, trademark law is perfectly indifferent to this case; when the
modified package is not advertised, marketed, sold, or otherwise used
in commerce under the trademark, there is no case for trademark
infringement (AIUI, IANAL).  A trademark license can of course be
conditioned on the licensee's agreement to arbitrary constraints,
since (like a copyright license) it is an offer of contract; but the
offer on the table from the Mozilla Foundation more nearly resembles a
unilateral grant, articulating a "safety zone" within which no license
as such is required, and places no onus on Debian to ensure that
recipients of the Debian package don't further re-work it.

> > A quick reminder of what's at risk here: if the private key of a root
> > cert trusted by Firefox became compromised, _any_ SSL transaction that
> > any user trusting that cert performed could be silently MITMed and
> > eavesdropped on.
> 
> Let's be serious here. You've already got the verisign certificates,
> and you've got a helpful dialog box that appears whenever new
> certificates are presented to the browser such that the user can just
> whack 'ok' without reading it. SSL security on the internet at large
> is a myth. Anybody who trusts it is insane; the risks aren't very
> significant.

Information security in general is a myth, but like many myths it has
utility in some contexts.  If you feel some degree of responsibility
for ensuring the good conduct of someone else, then it's wise to make
good conduct convenient for them and bad conduct as inconvenient,
risky, and easy to detect as possible.  Site admins who care can make
it quite inconvenient for the user to "whack 'ok'" when there is no
chain of trust to a root cert, and can back this up with logging to
make it easy to detect and a site policy to make it risky.  Selecting
root certs carefully can make it relatively convenient for a
legitimate site to establish a chain of trust and relatively
inconvenient to undermine that trust.

None of this is anything resembling foolproof -- or rather clever,
determined, non-risk-averse, expendable attacker-proof.  But it's
sophomoric to claim that ease of circumvention by an unsupervised user
would justify a cavalier attitude to root cert security on the part of
the Mozilla Foundation.

Cheers,
- Michael