Prices You Can Afford - Quality You Can Trust

[Bobby]

We have been helping thousands of men with male enhancement 
http://qudk.roukvs92oj9hda9.carucatedlf.info




Everybody winds up kissing the wrong person good night.
Practice, the master of all things.   
University politics are vicious precisely because the stakes are so small.  




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

Re: GCC version change / C++ ABI change

[Horms]

On Mon, Jul 04, 2005 at 03:07:23AM +0200, Matthias Klose wrote:
> Junichi Uekawa writes:
> > Hi,
> > 
> > > This week, we will change the GCC default versions from 3.3 to 4.0
> > 
> > Would it break kernel 2.4 builds somehow ?
> 
> No, you can still build using gcc-3.3.

I have added this as a build dependancy for all the kernel images that
are in the kernel team's svn tree, that is alpha, hppa, i386, ia64,
mips, powerpc, s390 and sparc.  This should appear in their respective
next releases. I have CCed the uploaders of these packages, if you are
one of those people and have a reason to undo this change, please do so,
I have no ambitions to tread on your toes.


-- 
Horms


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

Re: HashKnownHosts

[Peter Samuelson]

[Martijn van Oosterhout]
> To be honest, I think it would be far more useful to timestamp each
> entry so you can simply expire old ones.

Last access time, it'd have to be, not create time.  Meaning, every
time ssh runs, it rewrites .ssh_known_hosts (and not just appends to
it).  Which implies locking, possibly over NFS, which is particularly
enjoyable.

Well, if the timestamp representation is fixed-length I suppose you
don't really have to lock the file


signature.asc
Description: Digital signature

Re: Debian 3.1r0 CD/DVD image problem

[Terry Hancock]

On Thursday 09 June 2005 08:17 pm, Kenneth Stailey wrote:
> --- Anonymous <[EMAIL PROTECTED]> wrote:
> 
> > >> Can't the remainder of the third DVD be filled up 
with multimedia
> > >> propoganda files or other fluff?
> 
> > > Or 3vil planz for world domination?
> 
> > If all elve fails fill it up with pr0n. ;)
> 
> We have to uphold the maxim: Data Expands To Fill All 
Existing Storage!

Hey, it's a DVD, it needs to have the "Making Of  Debian 3.1 
'Sarge'" movie on it!

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com


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

Targeted - OnDemand Users

[Sousa M. Elmo]

Good day sir,

This just in - 2005 Digital Filters have just been released 
with the latest Pass-Through technology video bypass chip.
At this time, it's the only digital filter on the market 
today that you can get with the new lockup buster technology!

Now you can get Sports, HBO, Cinemax, Starz, Adult Channels, 
OnDemand, Music Channels, all the "extra" channels without
having to pay extra for them!

Goto Our Page between the arrows below : 

-> -> -> -> goodperform.info/ppv <- <- <- <-

Get back to you later,
Sousa M. Elmo
[EMAIL PROTECTED]

Re: GCC version change / C++ ABI change

[Otavio Salvador]

Thiemo Seufer <[EMAIL PROTECTED]> writes:

> Junichi Uekawa wrote:
>> Hi,
>> 
>> > This week, we will change the GCC default versions from 3.3 to 4.0
>> 
>> Would it break kernel 2.4 builds somehow ?
>> I've not been quite following; but the thread almost a month ago
>> seems to indicate thus:
>> http://www.kerneltraffic.org/kernel-traffic/kt20050701_316.html#7
>
> Quite likely, yes. 2.4 Kernels would need to Build-Dep on 3.4.

But the current versions of 2.4 doesn't get fixed yet?

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


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

Bug#316807: ITP: hiptex -- LaTeX package for writing Church Slavonic texts in HIP encoding

[Ivan Raikov]

Package: wnpp
Severity: wishlist

* Package name: hiptex
  Version : 0.7.0
  Upstream Author : Alexander V. Voinov
* URL or Web page : http://str12.sobor.org/hip/
* License : LaTeX Project Public License
  Description : LaTeX package for writing Church Slavonic texts in HIP 
encoding

 HIPTeX is a LaTeX package for writing Church Slavonic texts in HIP
 encoding. HIP is a system to represent Church Slavonic text using the
 standard  Cyrillic alphabet and a small number of ASCII symbols. HIP
 was  developed as part of project Pechatnyj Dvor (Printing House)
 . 

 The package includes the hipfonts style, which allows inclusion of
 Church Slavonic text in an arbitrary LaTeX document, and the hipbook
 class, which provides book definitions corresponding to the
 liturgical book conventions of the Russian orthodox church.


-- 
"To argue with a person who has renounced the use of reason is like
 administering medicine to the dead." --Thomas Paine



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

Re: GCC version change / C++ ABI change

[Matthias Klose]

Junichi Uekawa writes:
> Hi,
> 
> > This week, we will change the GCC default versions from 3.3 to 4.0
> 
> Would it break kernel 2.4 builds somehow ?

No, you can still build using gcc-3.3.


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

Re: GCC version change / C++ ABI change

[Thiemo Seufer]

Junichi Uekawa wrote:
> Hi,
> 
> > This week, we will change the GCC default versions from 3.3 to 4.0
> 
> Would it break kernel 2.4 builds somehow ?
> I've not been quite following; but the thread almost a month ago
> seems to indicate thus:
> http://www.kerneltraffic.org/kernel-traffic/kt20050701_316.html#7

Quite likely, yes. 2.4 Kernels would need to Build-Dep on 3.4.


Thiemo


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

Re: GCC version change / C++ ABI change

[Junichi Uekawa]

Hi,

> This week, we will change the GCC default versions from 3.3 to 4.0

Would it break kernel 2.4 builds somehow ?
I've not been quite following; but the thread almost a month ago
seems to indicate thus:
http://www.kerneltraffic.org/kernel-traffic/kt20050701_316.html#7


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]

Re: HashKnownHosts

[Stig Sandbeck Mathisen]

On Jul 2, 2005, at 19:40, Olaf van der Spek 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?


It looks like it will make the TAB  hostname completion break, if you  
use bash_completion.



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

Re: HashKnownHosts

[Robert Collins]

On Sun, 2005-07-03 at 18:36 +0200, Martijn van Oosterhout wrote:

> One case I can think of is where you regularly ssh into a machine with
> a dynamic IP address. Maybe with or without a dyndns name. Depending
> on the size of the ISP and how often the address changes the
> known_hosts files could increase without bound.

Theres a ~/.ssh/config option for that. HostsKeyAlias or something.

Rob

-- 
GPG key available at: .


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

Bug#316781: ITP: clamtk -- A GUI frontend for ClamAV

[Dave Mauroni]

Package: wnpp
Severity: wishlist
Owner: Dave Mauroni <[EMAIL PROTECTED]>


* Package name: clamtk
  Version : 2.02
  Upstream Author : Dave Mauroni <[EMAIL PROTECTED]>
* URL : http://clamtk.sourceforge.net
* License : Artistic
  Description : A GUI frontend for ClamAV

ClamTk is a GUI frontend for ClamAV using Gtk2-perl.
It is designed to be a lightweight and easy-to-use
virus scanner.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Re: HashKnownHosts

[Florian Weimer]

* Colin Watson:

> That's true. You can add them by hand without hashing the host name (and
> use 'ssh-keygen -H' afterwards if you like); known_hosts may contain a
> mix of hashed and unhashed host names.
>
> Is this a feature you would use often?

It might be practical for those of us who copy SSH host keys from
trusted sources (IOW nobody).  Probably it's okay to list the host in
an unhashed form in this case, provided that this feature doesn't go
away.

>> and it does not allow removal of all entries with a specific hash.
>
> If you know the host name, 'ssh-keygen -R' will do that. If you don't, I
> am curious as to the use case.

Sorry, I didn't wrote what I meant.  I've got some host name and what
to remove all lines which point to the same logical host (with the
same public key).  Sometimes it's necessary to sanitize the
known-hosts file (because the hosts still can be recovered using a
dictionary attack, or based on the stored public key).


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

Re: HashKnownHosts

[Colin Watson]

On Sun, Jul 03, 2005 at 08:25:51PM +0100, Jochen Voss wrote:
> On Sun, Jul 03, 2005 at 12:20:47AM +0100, Colin Watson wrote:
> > On Sat, Jul 02, 2005 at 11:42:40PM +0200, Marco d'Itri wrote:
> > > 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; ...
> 
> Are you both speaking about ~/.bash_history by chance?

At least I meant that, yes.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: HashKnownHosts

[Jochen Voss]

Hello,

On Sun, Jul 03, 2005 at 12:20:47AM +0100, Colin Watson wrote:
> On Sat, Jul 02, 2005 at 11:42:40PM +0200, Marco d'Itri wrote:
> > 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; ...

Are you both speaking about ~/.bash_history by chance?

All the best,
Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

Adoption: gnomad2 gnusim8085 neutrino robotour swt-motif vbpp vbs

[Shaun Jackman]

I've recently put a number of my packages up for adoption, mostly
because I no longer use them. They are all in good shape, and haven't
been much trouble. Here's the list:

gnomad2 - Manage a Creative Labs Nomad Jukebox
gnusim8085 - Graphical Intel 8085 simulator
neutrino - GNOME shell for managing your Creative Labs Nomad Jukebox
robotour - control mobile robots in this programmer's game
swt-motif - Standard Widget Toolkit for Motif
vbpp - Verilog preprocessor
vbs - Verilog Behavioral Simulation

Please note that swt-gtk is not up for adoption. I haven't put
swt-pocketpc up for adoption, but if someone is particularly
interested in it, I'd be willing to pass on the torch.

If anyone uses the Pocket PC toolchain (pocketpc-binutils,
pocketpc-cab, pocketpc-gas, pocketpc-gcc, pocketpc-sdk) I'd be
interested in a co-maintainer.

Cheers,
Shaun

World first Patch Technology for penis Enlargement

[Peter]

No pills, no pumps - Its the Patch
http://www.siratu.com/ss/





Talk of nothing but business, and dispatch that business quickly.   
A desk is a dangerous place from which to watch the world. 
Toughness doesn't have to come in a pinstriped suit.
It is a profitable thing, if one is wise, to seem foolish. 
Procrastination is the thief of time.   




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

Re: HashKnownHosts

[Bob Proulx]

Martijn van Oosterhout wrote:
> One case I can think of is where you regularly ssh into a machine with
> a dynamic IP address. Maybe with or without a dyndns name. Depending
> on the size of the ISP and how often the address changes the
> known_hosts files could increase without bound.

I don't believe the IP address is really significant and I turn that
off in my config.

  CheckHostIP no

This prevents the IP from being stored in the known hosts file.

Bob


signature.asc
Description: Digital signature

Re: Debian Java in Sarge

[Ola Lundqvist]

Hello

On Sat, Jun 04, 2005 at 05:17:18PM -0500, Adam Heath wrote:
> On Sat, 4 Jun 2005, Josselin Mouette wrote:
> 
> > Le vendredi 03 juin 2005 à 18:41 -0500, Adam Heath a écrit :
> > > > I agree.  A java policy should talk about how java packages should 
> > > > interact
> > > > once installed.  But stay the hell away from how they are built.
> > >
> > > As an example, debhelper, while being very useful for maintainers, is not
> > > mandated.
> >
> > That doesn't make not using it less stupid. The few times I saw a
> > package not using debhelper, it was broken in some way.
> 
> Of course.  That doesn't mean it should be mandated.
> 
> 

Please do not mandate anything if it is not strictly necessary.

Regards,

// Ola

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

Re: HashKnownHosts

[Martijn van Oosterhout]

2005/7/3, Colin Watson <[EMAIL PROTECTED]>:
> On Sun, Jul 03, 2005 at 03:28:15PM +0200, Bernd Eckenfels wrote:
> > In article <[EMAIL PROTECTED]> you wrote:
> > > That's true, and unavoidable in this scheme; but the use case (beyond
> > > fastidiousness) for this is not clear to me.
> >
> > Well, how do you audit the files and purge stale entries.
> 
> That comes under "fastidiousness" as far as I'm concerned: the only
> benefits I see from bothering to do that are (a) negligible performance
> differences and (b) hiding of old information, which HashKnownHosts
> gives you anyway. I don't see how it's required for normal use. Joe User
> is never going to garbage-collect his known_hosts file; heck, even I
> have better things to do. The only time I've ever removed entries from
> known_hosts is when I know that a specific host's key has changed, and
> 'ssh-keygen -R' deals with that just fine.

One case I can think of is where you regularly ssh into a machine with
a dynamic IP address. Maybe with or without a dyndns name. Depending
on the size of the ISP and how often the address changes the
known_hosts files could increase without bound.

Even with a dyndns name, the known_hosts file has both the DNS name
and the IP address. If you remove the hash based on DNS name, does it
remove *all* known_hosts with IP addresses with the same public key?
The documentation for -R quoted doesn't state either way.

To be honest, I think it would be far more useful to timestamp each
entry so you can simply expire old ones. Looking through my
known_hosts file now I see lots of duplicate entries (same host,
different names) and hosts which I only ever logged into once. As well
as hosts that no longer exist or no longer accessable to me. With the
names I guess, with hashes you're stuffed. I think I can confidently
say that >80% of my known_hosts file is redundant but I can only tell
by seeing the names/IP addresses...

> (Of course, people with unusual requirements can always disable
> HashKnownHosts, but I'm interested in a sane default.)

Whether my situation is unusual or not I have no idea. This machine is
about 5 years old and has been connected to a lot of networks and
machines over its lifetime, each of which leaves a line or two in my
known_hosts...

I think if another way was provided to manage file growth it wouldn't
be so much of an issue...

Re: HashKnownHosts

[Colin Watson]

On Sun, Jul 03, 2005 at 11:08:38AM +0200, Florian Weimer wrote:
> * Colin Watson:
> > On Sat, Jul 02, 2005 at 09:04:18PM +0200, Florian Weimer wrote:
> >> 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.
> 
> AFAICS, ssh-keygen does not permit adding new entries,

That's true. You can add them by hand without hashing the host name (and
use 'ssh-keygen -H' afterwards if you like); known_hosts may contain a
mix of hashed and unhashed host names.

Is this a feature you would use often?

> and it does not allow removal of all entries with a specific hash.

If you know the host name, 'ssh-keygen -R' will do that. If you don't, I
am curious as to the use case.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

GCC version change / C++ ABI change

[Matthias Klose]

This week, we will change the GCC default versions from 3.3 to 4.0
(for g77 and gpc to 3.4, these are not supported in 4.0) on all
architectures. The GCC-4.0 version used is taken from the GCC 4.0
branch (something that will likely become the 4.0.1 release candidate
3). The switch to 4.0 (instead to 3.4) is preferred by the Debian GCC
maintainers and the port maintainers (modulo those I forgot to ask,
please speak up now). Looking forward at the etch release schedule, it
is unlikely that 3.4 is still supported upstream in 18 months. 4.0 is
currently used on by other distributions as a system compiler to build
most of the distribution. We will keep at least the GCC-3.4 C and
Fortran77 compilers for the etch release.

The C++ ABI change was already announced at

  http://lists.debian.org/debian-release/2005/04/msg00153.html

There has been a concern about re-renaming library packages
libfoo1c102 back to libfoo1, because this might break third party
packages on systems, that are directly upgraded from potato to etch.
I don't know any of these, but if a package maintainer thinks it's
worth supporting these packages and upgrades, please rename the
package to libfoo1c2. In this case you have to keep the libfooc1
conflict/replace and add the libfoo1c102 conflict/replace.

The timeframe for the change is as follows:

 - wait for gcc-4.0 4.0.0-11 in the archives on all architectures,
   for sparc and hppa we require the -12 version (Looking at the
   buildds, that probably will be 2005-07-0[56]).

 - wait for gcc-3.4 3.4.4-3 in the archives on all architectures,
   although 3.4.4-4 would be preferred (same estimates as for
   gcc-4.0).

 - an upgrade to binutils-2.16.1 is a nice to have, currently needs
   some more work on mips/mipsel.

 - upgrade gcc-defaults to point to the 4.0 compiler drivers.

 - upgrade build-essential to version 11 to depend on the new
   defaults.

PLEASE do NOT start uploading packages before a new gcc-defaults and
build-essential are in the archives.

After these are in the archives: The following can happen in parallel:

 - Rebuild C++ applications, which do not depend on any other C++
   library besides libstdc++.

 - Rename and rebuild C++ libraries, which do not depend on any
   other C++ library besides libstdc++.

All other applications and libraries have to wait, until the C++
related build dependencies are available for the new ABI. It's
important to adjust the build dependencies and the dependencies of the
-dev packages to the first version of a package, which is built for
the new ABI.

Please don't add build dependencies on g++ (>= 4.0) or build-essential
(>= 11). The buildd maintainers will take care, that the buildd's run
with build-essential-11 after it's in the archives.

I'm updating the above mentioned text for the C++ ABI until Wednesday
or Thursday. Feedback and additions are welcome.

For the time until all C++ libraries are converted, I'm proposing the
following NMU policy:

- 0-day NMU's allowed for all C++ library packages, which are uploaded
  after the g++ default change, and are completely ignoring the C++
  ABI change.

- 2-day NMU's allowed for all C++ library packages, which are uploaded
  after the g++ default change, with serious bugs in the packaging
  (i.e. wrong package name in shlibs file, missing conflicts/replaces,
  library package without a library, etc).

- 5-day NMU for all C++ library packages, which can be converted, but
  are left alone.


Matthias

PS: Some of you know, that Ubuntu did the C++ ABI change at the start
of it's release cycle.  For most if the libraries, patches are
available. These have to be adjusted, at least for the version
numbers. Some Debian developers think these patches are too simple,
and it doesn't make sense to submit those to the Debian BTS. All
others may have a look at http://wiki.ubuntu.com/CxxLibraryList


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

Re: HashKnownHosts

[Colin Watson]

On Sun, Jul 03, 2005 at 05:16:08PM +0200, Kurt Roeckx wrote:
> On Sun, Jul 03, 2005 at 03:52:07PM +0100, Colin Watson wrote:
> > The only time I've ever removed entries from
> > known_hosts is when I know that a specific host's key has changed, and
> > 'ssh-keygen -R' deals with that just fine.
> 
> That options seems to be undocumented.  It's not in the man page
> or the help it show at the command line.  But it does seem to
> exist.  (It doesn't give an error.)

It is in fact in the man page, at least in 4.1p1. You're correct that
it's missing from the command-line help; this was fixed in upstream CVS
after 4.1p1, and will be in 4.2p1.

> It also looks rather weird to me to use a tool to generate your
> key to manage the public key of other hosts.

It's slightly odd placement, yes.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: Getting rid of circular dependencies

[Colin Watson]

On Sun, Jul 03, 2005 at 04:57:58PM +0200, Ola Lundqvist wrote:
> On Fri, Jun 24, 2005 at 05:21:51PM +0200, Bill Allombert wrote:
> >  `Depends'
> >   This declares an absolute dependency.  A package will not be
> >   configured unless all of the packages listed in its `Depends'
> >   field have been correctly configured.
> 
> This phrasing is obviously wrong as you can install packages with
> circular dependencies. This phrasing say exactly what Pre-Depends is.
> 
> Depends should be described as follows:
> 
>   `Depends'
>This declares an absolute dependency.  A package will not be
>configured unless all of the packages listed in its `Depends'
>field have been correctly unpacked.

This is incorrect. Depends is as described in policy, with the addition
that dpkg will arbitrarily break loops.

For the meaning of Pre-Depends, see policy.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: HashKnownHosts

[Kurt Roeckx]

On Sun, Jul 03, 2005 at 03:52:07PM +0100, Colin Watson wrote:
> The only time I've ever removed entries from
> known_hosts is when I know that a specific host's key has changed, and
> 'ssh-keygen -R' deals with that just fine.

That options seems to be undocumented.  It's not in the man page
or the help it show at the command line.  But it does seem to
exist.  (It doesn't give an error.)

It also looks rather weird to me to use a tool to generate your
key to manage the public key of other hosts.


Kurt


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

Re: Getting rid of circular dependencies

[Ola Lundqvist]

Hello

On Fri, Jun 24, 2005 at 05:21:51PM +0200, Bill Allombert wrote:
> Dear Debian developers,
> 
> Following a post to Debian-Devel-Announce, I would like to
> discuss getting rid of circular dependencies.
> 
> Why ?
> -
> 1) The semantic of Depends specified by Debian policy 7.2. does not allow
> packages with circular dependencies to be installed at all:
> 
>  `Depends'
>   This declares an absolute dependency.  A package will not be
>   configured unless all of the packages listed in its `Depends'
>   field have been correctly configured.

This phrasing is obviously wrong as you can install packages with
circular dependencies. This phrasing say exactly what Pre-Depends is.

Depends should be described as follows:

  `Depends'
   This declares an absolute dependency.  A package will not be
   configured unless all of the packages listed in its `Depends'
   field have been correctly unpacked.

But I actually think you may have made a mistake by saying that
configured refer to the configure phase in dpkg install. It could be
clarified though.

> This mean that dpkg have to go out of its way to install them, and doing
> that break the expectation of packages expecting Depended package to be
> configured before them.
> 
> 2) There have been lots of evidence that circular dependencies create
> problems during upgrade.  See bugs #310490 in particular
> <[EMAIL PROTECTED]>.

This may be the case, but I think that this may be a problem in aptitude
more than in the existance of circular dependencies. Well I'm not the
one to determine this.

Removing unneeded circular dependencies is a good thing though. Especially
for big chunks of packages.

> 3) Circular dependencies make the job of the testing scripts harder.

Yes that is true.

> 4) Circular dependencies make bootstrapping a new plateform harder.

True also.

> 5) There is an urban legend that circular dependencies between packages
> build from the same source are harmless. This is false of course. Being
> part of the same source package has no effect of the Packages.gz file
> whatsoever.

It is true for case 3 and 4 above (at least 4 as I not fully sure about case 3).

> Which ?
> ---
> 
> Preferably all of them.
> 
> Robert Lemmen was kind enough to set up a summary of current circular
> dependencies: 
> See the list for yourself.
> 
> The circular dependencies involving the largest number of packages are:
> 
> * libxtst6 libxtrap6 libxrandr2 libxp6 libxt6 libxmu6 libxi6 libxrender1
> libxft1 libsm6 xlibs
> 
> * libgnorba27 libgnomeui32 libgnomesupport0 gnome-bin gnome-libs-data 
> libgnome32
> 
> * xemacs21-gnome-nomule xemacs21-gnome-mule-canna-wnn xemacs21-gnome-mule 
> xemacs21-nomule xemacs21-mule-canna-wnn xemacs21-bin xemacs21-support
> xemacs21-mule xemacs21
> 
> * gnome-panel-data gnome-panel nautilus gnome-control-center capplets
> gnome-session
> 
> * phpgroupware-preferences phpgroupware-admin phpgroupware-setup
> phpgroupware-phpgwapi phpgroupware
> 
> * wesnoth-tdh wesnoth-ei wesnoth-sotbe wesnoth-trow wesnoth-httt
> wesnoth-data wesnoth
> 
> How ?
> -
> 
> I see two easy case:
> 
> 1) foo and foo-data. There is usualy no reason for foo-data to depend on
> foo. foo-data does not provide user-visible interface, only data, so it
> does not need to depend on foo.
> 
> 2) libfoo and foo-bin, where foo-bin include binaries linked with
> libfoo. Usually libfoo only need to Depends on configuration data
> in foo-bin and not on any binaries linked with libfoo (to avoid infinite
> recursion). In that case it should be possible to split foo-bin in
> foo-bin and foo-common, and change libfoo to depend on foo-common
> instead.

Regards,

// Ola

> Other options ?
> 
> Cheers,
> -- 
> Bill. <[EMAIL PROTECTED]>
> 
> Imagine a large red swirl here. 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 

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

Re: HashKnownHosts

[Colin Watson]

On Sun, Jul 03, 2005 at 03:28:15PM +0200, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > That's true, and unavoidable in this scheme; but the use case (beyond
> > fastidiousness) for this is not clear to me.
> 
> Well, how do you audit the files and purge stale entries.

That comes under "fastidiousness" as far as I'm concerned: the only
benefits I see from bothering to do that are (a) negligible performance
differences and (b) hiding of old information, which HashKnownHosts
gives you anyway. I don't see how it's required for normal use. Joe User
is never going to garbage-collect his known_hosts file; heck, even I
have better things to do. The only time I've ever removed entries from
known_hosts is when I know that a specific host's key has changed, and
'ssh-keygen -R' deals with that just fine.

(Of course, people with unusual requirements can always disable
HashKnownHosts, but I'm interested in a sane default.)

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: HashKnownHosts

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> That's true, and unavoidable in this scheme; but the use case (beyond
> fastidiousness) for this is not clear to me.

Well, how do you audit the files and purge stale entries.

Gruss
Bernd


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

Re: HashKnownHosts

[Colin Watson]

On Sun, Jul 03, 2005 at 12:17:13AM +0100, Colin Watson wrote:
> On Sat, Jul 02, 2005 at 11:19:26AM +0200, Marco d'Itri wrote:
> > (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.

Adam Conrad suggested an easy way to do this to me on IRC, so thanks to
him this is now fixed in CVS.

Thanks,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: HashKnownHosts

[Colin Watson]

On Sun, Jul 03, 2005 at 02:16:08AM +0200, Marco d'Itri wrote:
> On Jul 03, Colin Watson <[EMAIL PROTECTED]> wrote:
> > 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.

That's true, and unavoidable in this scheme; but the use case (beyond
fastidiousness) for this is not clear to me.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: HashKnownHosts

[Florian Weimer]

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

AFAICS, ssh-keygen does not permit adding new entries, and it does not
allow removal of all entries with a specific hash.


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

UNSUBSCRIBE

[Benjamin Azan]

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

Debian Mirror Problem

[Johann Glaser]

Hi!

For a few weeks there are discrepancies between some "Packages" files
and the files in the ./pool/ directory. Unfortunately the debian-mirrors
list is dead since the end of 2003. Therefore I try to ask this list, if
you know anything about this discrepancy, if you can point me where I
should ask or if I can ask the details in this list.

Thanks
  Hansi



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

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Michael K. Edwards]

On 7/3/05, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 02, 2005 at 05:35:09PM -0700, Michael K. Edwards wrote:
> > 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).
> 
> And?
> 
> It's not because Debian doesn't advertise, market, sell, or otherwise
> use in commerce its own modified package that other people don't do
> that. Think of people selling CD images, preinstalled computers...

Note that I was responding specifically to a concern raised by Andrew
about whether the Mozilla Foundation's objections to adding root certs
to the Firefox package would affect corporate site admins who rebuild
Debian's Firefox.  As I see it, that is indeed a legitimate scenario
for downstream alteration of the root cert list, but that's OK -- the
trademark "safety zone" automatically extends to the site admin, since
she is not marketing her altered package under the trademark.

In other words, adding root certs is a common case; but adding root
certs _and_marketing_the_result_ is a corner case.  I don't have a
problem with a clause in a trademark policy that says, "the 'safety
zone' for descriptive use of our trademark on modified builds does not
extend to people who add root certs without our approval and advertise
or sell the result under our trademark."  I think it's fair to say
that QA on the root cert list is rather central to the QA of a
"secure" browser, and for the Mozilla folks to call this out as a
sensitive issue is not only reasonable but perhaps (IANAL) necessary
if they want to retain the trademark.

Cheers,
- Michael

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Wouter Verhelst]

On Sat, Jul 02, 2005 at 05:35:09PM -0700, Michael K. Edwards wrote:
> 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).

And?

It's not because Debian doesn't advertise, market, sell, or otherwise
use in commerce its own modified package that other people don't do
that. Think of people selling CD images, preinstalled computers...

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