Re: Considerations for 'xmms' removal from Debian

[Oleg Verych]

* 07-08-2007, Andrei Popescu:
[]
> Did you even try adding a directory? It might even work ;)
>
>> xmms2... Well, when we have a decent client, then can are an option.
>> Now, isn't it.
>
> Same as with mpd :-/

Server is `(mu-)mplayer` (seek isn't working in ogg), client is `dd`,
playlist is small `sh` script: ftp://flower.upol.cz/mu-player/

> Regards,
> Andrei
> --=20
> If you can't explain it simply, you don't understand it well enough.
> (Albert Einstein)

--
  Hard to disagree :)


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

Re: RFC: changes to default password strength checks in pam_unix

[Oleg Verych]

04-09-2007, John Kelly:
> On Sep 3, Lars Wirzenius wrote:
>
>>ti, 2007-09-04 kello 10:17 +0900, Miles Bader kirjoitti:
>
>>> If the system is excessively anal about what passwords it will let you
>>> use, people will just start writing them down...
>
>>That is arguably better than having passwords which can be guessed by
>>doing brute-force attackes over ssh.
>
> I stop brute force attacks by sending auth log messages to a FIFO which I 
> read with a perl script. After 10 login failures, your IP is firewalled for 
> 24 hours.

What about having more secure Debian's sshd_config by default?
"
PermitRootLogin no
DenyUsers   *
"
to start with.

Also i would really love to have sshd rc script being able to load
different configs easily. I have dummy sshd on 22 port and one actual
door on another. Having more dummy services else where, is more "security
by obscurity". Not 100% protection, but something.



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

Re: RFC: changes to default password strength checks in pam_unix

[Petter Reinholdtsen]

[Steve Langasek]
> Right, I know there are going to be use cases where 6 is too long
> for the minimum length, and users will need to lower the setting in
> /etc/pam.d/common-password.  Do you think we need to provide some
> hook for these Debian Edu users to change the setting automatically,
> via preseeding or otherwise, or do you think users this is a corner
> case even within Debian Edu?

I'm not sure.  Personally, I want to enforce strong passwords, but I
realize that it will be a hard sell in some environment and that we
could loose installations if we make it too hard to avoid such
enforcing.

Some schools even use the same password for all lower grade users
instead of providing very easy passwords, and I am not sure if that is
better.  I am convinced the schools will come up with some new an
innovative insecure way to work around any enforced password policy,
so it might not matter either way. :)

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: RFC: changes to default password strength checks in pam_unix

[John Kelly]

On Tue, 4 Sep 2007 07:53:08 + (UTC), Oleg Verych
<[EMAIL PROTECTED]> wrote:

>What about having more secure Debian's sshd_config by default?

>PermitRootLogin no
>DenyUsers   *

Doing remote ssh installations without any console access will make
you unhappy with that default.


-- 
Internet service
http://www.isp2dial.com/
 

Re: RFC: changes to default password strength checks in pam_unix

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/04/07 03:10, Petter Reinholdtsen wrote:
[snip]
> 
> Some schools even use the same password for all lower grade users
> instead of providing very easy passwords, and I am not sure if that is
> better.

That's just stupid.

Since first grade, my children have been able to remember their own
passwords.  Sure, they were simple at first ("dog" and "cat"), but
now in third grade they are relatively sophisticated.

> I am convinced the schools will come up with some new an
> innovative insecure way to work around any enforced password policy,
> so it might not matter either way. :)

- --
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG3RgqS9HxQb37XmcRAtOqAJ9ZmnJ0nsPR3IJlVOk9vgyoGkmr3wCfaZEH
stWe4OraHAZcNrEJuzxE79c=
=tv0u
-END PGP SIGNATURE-


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

Re: RFC: changes to default password strength checks in pam_unix

[Lars Wirzenius]

ma, 2007-09-03 kello 23:40 -0400, John Kelly kirjoitti:
> On Sep 3, Lars Wirzenius wrote:
> >That is arguably better than having passwords which can be guessed by
> >doing brute-force attackes over ssh.
> 
> I stop brute force attacks by sending auth log messages to a FIFO which I 
> read with a perl script. After 10 login failures, your IP is firewalled for 
> 24 hours.
> 
> Works great.

I'm sure it does work great. Can you work on making sure it is the
default in lenny if openssh-server is installed?

-- 
Talk is cheap. Whining is actually free.


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

Re: RFC: changes to default password strength checks in pam_unix

[Antti-Juhani Kaijanaho]

On Mon, Sep 03, 2007 at 11:40:07PM -0400, John Kelly wrote:
> I stop brute force attacks by sending auth log messages to a FIFO which I 
> read with a perl script. After 10 login failures, your IP is firewalled for 
> 24 hours.

I have a rate-limiting iptables ruleset for SSH (and HTTP).  In my
experience, brute force attackers give up after the rate-limiter starts
tarpitting them.

See http://antti-juhani.kaijanaho.fi/stuff/ratelimit.txt

- 
Antti-Juhani Kaijanaho, Jyväskylä
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/


signature.asc
Description: Digital signature

Re: RFC: changes to default password strength checks in pam_unix

[Roger Leigh]

Steve Langasek <[EMAIL PROTECTED]> writes:

> For years, the Debian pam packages have by default had a weaker password
> length requirement than upstream.  I can think of no reason for this to be
> the case, especially when upstream doesn't support a configurable minimum
> password length and Debian does.
>
> Does anyone else have a reasoned argument why Debian should have a weaker
> password length check than upstream (4 chars instead of 6)?  If not, this
> will be changed in the next upload of pam.

I think making it 6 would be a good idea.

However, I think 8 as a default may be too long.

Having enabled the cracklib stuff in pam_unix while testing the new
PAM, I agree that this should remain disabled.  Many users (including
myself) find the enforcement of all those extra checks annoying, and I
agree with other comments that extra checks don't always result in
more security due to tacking fixed patterns onto a shorter password.
It would be nice to make the pam_unix cracklib stuff configurable in
configure, so we don't need to patch the Makefiles, and push that
upstream.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


pgpw3XfkBQtGz.pgp
Description: PGP signature

Re: packages.debian.org updated

[Frank Lichtenheld]

On Tue, Sep 04, 2007 at 07:34:34AM +0200, Lionel Elie Mamane wrote:
> (Please CC me on replies; thanks.)
> 
> On Sun, Sep 02, 2007 at 10:58:12PM +0200, Frank Lichtenheld wrote:
> 
> > packages.debian.org was finally updated to the new code base that
> > was already available some time from packages.debian.net.
> 
> What are "similar packages"? I'm trying wrap my head around the fact
> it finds x-window-system-core similar to exim4, but not vice-versa.

Similar packages are found by using the Description and the Debtags
information of the package, doing a full text search with that and
return the best hits. I have no real idea why x-window-system-core
is considered a good hit for exim4 (But I guess it might have something
to do with the fact that the exim4 Description doesn't talk much about
what the package does and that it doesn't have any Debtags information).

The Debtags information is very influential in this search
(for reasons I'm too lazy to explain right now), so in this case where
one package has it and the other one not, the lists can look very different.

(The exact code can be seen at
http://source.djpig.de/git/?p=packages.git;a=blob;f=lib/Packages/Search.pm;hb=HEAD
starting with line 244)

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: debdelta, Re: proposed release goal: DEBIAN/md5sums for all packages

[Florent Rougon]

Jörg Sommer <[EMAIL PROTECTED]> wrote:

> Sorry, I can't remember the name of the package.

That must be cm-super.

-- 
Florent


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

Re: packages.debian.org updated

[Martin Zobel-Helas]

Hi, 

On Tue Sep 04, 2007 at 12:54:41 +0200, Frank Lichtenheld wrote:
> On Tue, Sep 04, 2007 at 07:34:34AM +0200, Lionel Elie Mamane wrote:
> > (Please CC me on replies; thanks.)
> > 
> > On Sun, Sep 02, 2007 at 10:58:12PM +0200, Frank Lichtenheld wrote:
> > 
> > > packages.debian.org was finally updated to the new code base that
> > > was already available some time from packages.debian.net.
> > 
> > What are "similar packages"? I'm trying wrap my head around the fact
> > it finds x-window-system-core similar to exim4, but not vice-versa.
> 
> Similar packages are found by using the Description and the Debtags
> information of the package, doing a full text search with that and
> return the best hits. I have no real idea why x-window-system-core
> is considered a good hit for exim4 (But I guess it might have something
> to do with the fact that the exim4 Description doesn't talk much about
> what the package does and that it doesn't have any Debtags information).
> 
> The Debtags information is very influential in this search
> (for reasons I'm too lazy to explain right now), so in this case where
> one package has it and the other one not, the lists can look very different.

There was some idea from Enrico and me earlier this year (i think it was
around FOSDEM) where he showed me how to use Debtags, Popcon and and a
small ruby(?) skript and produce a very nice output from it: 
"People who installed X also have packages Y, Z and T installed"

Any ideas how and if that can be integrated into p.d.o?

Greetings
Martin

-- 
[EMAIL PROTECTED] /root]# man real-life
No manual entry for real-life


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

Re: packages.debian.org updated

[Paul Wise]

On 9/4/07, Frank Lichtenheld <[EMAIL PROTECTED]> wrote:

> exim4 [...] doesn't have any Debtags information).

It does, but they are not reflected in the archive:

http://debtags.alioth.debian.org/edit.html?pkg=exim4

I've noticed a couple of other packages like this (eg flasm, tesseract-ocr).

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: debdelta, Re: proposed release goal: DEBIAN/md5sums for all packages

[Norbert Preining]

On Die, 04 Sep 2007, Florent Rougon wrote:
> > Sorry, I can't remember the name of the package.
> 
> That must be cm-super.

Yup, cm-super does this trick. I once wanted to undo this and ship the
font files directly, but got quite a lot of requests why the packages
has gotten soo big.

>From the rules file (with some additional comments):
# create md5sums for all but the type1 and the "container file"
# from which the fonts are created
dh_md5sums -p cm-super -X usr/share/texmf/fonts/type1/public/cm-super 
-X usr/share/cm-super
# create the correct md5sums for the files generated on postinst
(cd pfb ; for pfb in *.pfb ; do \
bn=`basename $$pfb .pfb` ; \
if ! grep -q "^$$bn$$" ../debian/fonts.cm-super-minimal
; then \
cat $$pfb | md5sum - | sed -e
"s|-|usr/share/texmf/fonts/type1/public/cm-super/$$pfb|" ; \
fi ; \
done) >> debian/cm-super/DEBIAN/md5sums
# add the md5sum of the empty file (t1c will be emptied on
# postinst)
echo "d41d8cd98f00b204e9800998ecf8427e usr/share/cm-super/cm-super.t1c" 
>> debian/$(package)/DEBIAN/md5sums


Best wishes

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
The Web site you seek
Cannot be located, but
Countless more exist.
   --- Windows Error Haiku


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

Re: Why no Opera?

[Dionysis Kalofonos]

[EMAIL PROTECTED] wrote:

Quoting Pierre Habouzit <[EMAIL PROTECTED]>:



[..]

I did not say I was too lazy to read the docmentation. There is too much 
for a person who has no clue where to begin and it is difficult to 
digest without the knowledge of how thigs work. It is well known that 
developers who write documentation often have no trouble understanding 
it because they already know everything although it is unfathomable to 
the rest of the world.




having followed this thread i have the impression that you are quite 
lost in the process of creating a package.


i hope i will help a bit by providing you with my notes on the 
information appearing in:

http://www.debian.org/doc/maint-guide/




# debian packaging
1) mkdir tmp && cd tmp

2) cvs -q export -r "TAG" -d project-X.X.X project  (if its in a cvs 
repository)


5) tar cvfz project-X.X.X.tar.gz ./project-X.X.X

6) cd project-X.X.X (go in root dir of source code)

7) dh_make -e [EMAIL PROTECTED] -f ../project-X.X.X.tar.gz

 debian-maint-guide ch2.4, p13 

8) edit control, copyright, rules (maybe works as is though), changelog, 
and any other files required


*) strace -f -o /tmp/log ./configure (or make instead of configure)

use the following script to find dependences (required for the control 
file):

#!/bin/bash
for x in `dpkg -S $(grep open /tmp/log|\
perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\
grep "^/"| sort | uniq|\
grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\
cut -f1 -d":"| sort | uniq`; \
do \
echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"`"), "; \
done
#eof

10) run dpkg-buildpackage -rfakeroot to make the package
11) dpkg -X project_X.X.X-1_i386.deb ./  to extract it and
   dpkg -c project_X.X.X-1_i386.deb to see the contents
   dpkg -I project_X.X.X-1_i386.deb to query the info

   lintian -i project_X.X.X-1_i386.changes
   linda -i project_X.X.X-1_i386.changes  to validate the package
# eof




the missing steps are those strongly related with my project.

As a last word allow me to say that i am a newbe and that i have made 
the above list as a reminder. However, i don't think that the above are 
meaningful without reading through the maintainers guide.


regards,
dionysis




--
Dionysis Kalofonos

Departamento de Informática
Universidad Carlos III de Madrid
Avda. de la Universidad, 30
28911, Leganés, Madrid, España
Edificio Sabatini, Despacho 2.1.C06

http://www.plg.inf.uc3m.es/~dkalofon
--


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

Re: RFC: dropping Linux capabilities support from pam_limits (bug #440130)

[Jörg Sommer]

Hi Steve,

Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 03, 2007 at 05:45:12PM +, Jörg Sommer wrote:
>
>> Steve Langasek <[EMAIL PROTECTED]> wrote:
>> > For a long time, the Debian pam package has been carrying a local patch to
>> > add support for Linux capabilities in pam_limits.  While catching up on bug
>> > triage work on the package, I've come to the conclusion that this
>> > functionality is broken, useless, and that no one actually uses it;
>
>> Sorry for this, maybe stupid, question, but how else can I change the
>> limits for an user? I see no other way than wrap the login shell with a
>> script that sets the limits.
>
> This was about dropping support for *Linux capabilities* in pam_limits, not
> about dropping pam_limits.

Ahh. I see. Sorry for the noice.

Jörg.
-- 
Damit das Mögliche entsteht, muß immer wieder das Unmögliche versucht
werden.   (Hermann Hesse)


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

Bug#440816: ITP: bytecode -- Java library to access bytecode

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller <[EMAIL PROTECTED]>


* Package name: bytecode
  Version : 0.92
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : LGPL
  Programming Lang: Java
  Description : Java library to access bytecode

The bytecode library comes with BioJava, a common library
to work with sequence data from computational biology.
.
 Homepage: http://www.biojava.org/

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash


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

Re: RFC: changes to default password strength checks in pam_unix

[John Kelly]

On Tue, 04 Sep 2007 12:31:15 +0300, Lars Wirzenius <[EMAIL PROTECTED]> wrote:

>> I stop brute force attacks by sending auth log messages to a FIFO which I 
>> read with a perl script. After 10 login failures, your IP is firewalled for 
>> 24 hours.
 
>I'm sure it does work great. Can you work on making sure it is the
>default in lenny if openssh-server is installed?

It's the type of thing an admin can do locally: set up syslog.conf so
that it copies auth log data to a FIFO:

> auth.info   -/var/log/auth
> auth.=notice-/var/log/auth.notice
> auth.=notice|/var/tmp/hostaccess.sshd

And then read it with a program or script which makes local decisions
on how to handle it.

If someone wants to take that idea and distribute it with debian, go
for it.  Personally, I don't have time to fight the political battle
that would ensue.


-- 
Internet service
http://www.isp2dial.com/
 

Bug#440822: ITP: dicelab -- evaluate the statistical distribution of dice rolls

[Robert Lemmen]

Package: wnpp
Severity: wishlist
Owner: Robert Lemmen <[EMAIL PROTECTED]>


* Package name: dicelab
  Version : 0.4
  Upstream Author : Robert Lemmen <[EMAIL PROTECTED]>
* URL : http://www.semistable.com/dicelab/
* License : GPL
  Programming Lang: C
  Description : evaluate the statistical distribution of dice rolls

 With dicelab you can express most dice rolls (and similar things) in a
 functional language, and the either roll the expression, or evaulate the
 statistical distribution. In the latter case you can choose whether you want 
to simply roll and tally many times, or actually compute the distribution (which
 is more precise, but takes a long time in some obscure cases).

smallish package by me :) 

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Bug#440823: ITP: kelbt -- backtracking LR parser

[Robert Lemmen]

Package: wnpp
Severity: wishlist
Owner: Robert Lemmen <[EMAIL PROTECTED]>


* Package name: kelbt
  Version : 0.12
  Upstream Author : Adrian Thurston <[EMAIL PROTECTED]>
* URL : http://www.cs.queensu.ca/~thurston/kelbt/
* License : GPL
  Programming Lang: C, C++
  Description : backtracking LR parser

 Kelbt generates backtracking LALR(1) parsers. Standard LALR(1) parser
 generators emit an error upon encountering a conflict in the parse tables.
 Kelbt forges onward, generating parsers which handle conflicts by backtracking
 at runtime. Kelbt is able to generate a parser for any context-free grammar 
and therefore implements a generalized parsing method.
 .
 Kelbt is different from other backtracking LR systems in two ways. First, it
 elevates backtracking to the level of semantic actions by introducing a class
 of actions called undo actions. Undo actions are invoked as the backtracker
 undoes parsing and allow the user to revert any side effects of forward
 semantic actions. This makes it possible to backtrack over language constructs
 which must modify global state in preparation for handling context
 dependencies.
 .
 Second, Kelbt enables a user-controlled parsing strategy which approximates
 that of generalized recursive-descent parsing with ordered choice. This makes
 it easy for the user to resolve language ambiguities by ordering the grammar
 productions of a non-terminal according to precedence. It is approximate in 
the sense that for most grammars the equivalent of an ordered choice parsing
 strategy is achieved. In cases where productions are parsed out of the order
 given, there is a simple grammar transformation which remedies the problem. 
See the CASCON paper for more details.
 .
 As a proof of concept, Kelbt has been used to write a partial C++ parser
 (included) which is composed of strictly a scanner, a name lookup stage and a
 grammar with standard semantic actions and semantic undo actions.

this is a companion to ragel (which is already in debian) and will be a 
build-dependency of it in the future

cu  robert

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: debdelta, Re: proposed release goal: DEBIAN/md5sums for all packages

[Russ Allbery]

Norbert Preining <[EMAIL PROTECTED]> writes:
> On Die, 04 Sep 2007, Florent Rougon wrote:

>> > Sorry, I can't remember the name of the package.
>> 
>> That must be cm-super.

> Yup, cm-super does this trick. I once wanted to undo this and ship the
> font files directly, but got quite a lot of requests why the packages
> has gotten soo big.

Ah, there are overrides.  That explains it.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: RFC: changes to default password strength checks in pam_unix

[Russ Allbery]

Roger Leigh <[EMAIL PROTECTED]> writes:

> Having enabled the cracklib stuff in pam_unix while testing the new
> PAM, I agree that this should remain disabled.  Many users (including
> myself) find the enforcement of all those extra checks annoying, and I
> agree with other comments that extra checks don't always result in
> more security due to tacking fixed patterns onto a shorter password.

I think you'll find that if the patterns that you use aren't ones that
cracklib knows, it *does* make the password more secure.  Why?  Because
guess how attackers try to crack passwords?  It's not like most of them
write their own password cracking software.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: RFC: changes to default password strength checks in pam_unix

[Joey Hess]

Steve Langasek wrote:
> Arguably if the consensus is that the default minimum password length should
> be raised in the users' best interests, we would want to change the
> makepasswd package's default at the same time.

And we might also want to make d-i do the same checks, currently it
enforces no minimum lengths at all..

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFC: changes to default password strength checks in pam_unix

[Adam D. Barratt]

On Tue, 2007-09-04 at 07:53 +, Oleg Verych wrote:
[...]
> What about having more secure Debian's sshd_config by default?
> "
> PermitRootLogin no

You'll have to convince the openssh package maintainers first - see
#105571, #298138 and #431627 for their opinions on whether that change
is "more secure".

Adam


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

Re: Bug#440823: ITP: kelbt -- backtracking LR parser

[Guus Sliepen]

On Tue, Sep 04, 2007 at 05:43:15PM +0200, Robert Lemmen wrote:

[...]
>   Description : backtracking LR parser
> 
>  Kelbt generates backtracking LALR(1) parsers. Standard LALR(1) parser

If it is a parser _generator_, mention this in de short description as
well.

>  generators emit an error upon encountering a conflict in the parse tables.
[...]
>  strategy is achieved. In cases where productions are parsed out of the order
>  given, there is a simple grammar transformation which remedies the problem. 
> See the CASCON paper for more details.
>  .
>  As a proof of concept, Kelbt has been used to write a partial C++ parser
>  (included) which is composed of strictly a scanner, a name lookup stage and a
>  grammar with standard semantic actions and semantic undo actions.

Which CASCON paper? I don't think you should mention this in the
description. The description is meant for a user to decide if he wants
to install this package or not. You shouldn't make a user follow
references, that is besides the point. I also don't think that the
paragraph about the proof of concept is useful. The only useful
information is "C++". Does Kelbt indeed output C++ code? 

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: menu policy & use of doc-base for programming documentation

[Frank Küster]

Stefano Zacchiroli  debian.org> writes:

> 
> On Thu, Aug 30, 2007 at 03:19:43PM -0400, Eric Cooper wrote:
> > The Debian OCaml maintenance team is looking at how to organize the
> > HTML documentation provided by the various OCaml packages.  Our first
> 
> Right, to add some details to that:
> - each library we have (will) ship an HTML documentation of the API,
>   generated with ocamldoc (the equivalent of javadoc). Such
>   documentation will be installed as /usr/share/doc/PACKAGE/html/api/
> - we just want to have a global HTML index which contain a listing of
>   all the library we ship as simple HTML links to the above pieces of
>   documentation
> 
> If possible we would like to avoid reinventing the wheel, and doc-base
> seems to be the right tool; it's just to restrictive: why should its
> categories be tight to the menu categories?

We have a similar problem with TeX documentation.  In my opinion, using menu
categories for doc-base might have been a good start, but we should definitely
extend that now.

I'm currently in semi-VAC mode and don't have time to discuss this or even check
the archives - but if I remember right, the problem is that there is no one who
really maintains doc-base.

Regards, Frank





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

Re: RFC: changes to default password strength checks in pam_unix

[Oleg Verych: gmane reading]

04-09-2007, Adam D. Barratt:

> On Tue, 2007-09-04 at 07:53 +, Oleg Verych wrote:
> [...]
>> What about having more secure Debian's sshd_config by default?
>> "
>> PermitRootLogin no
>
> You'll have to convince the openssh package maintainers first - see
> #105571, #298138 and #431627 for their opinions on whether that change
> is "more secure".

Thanks for references!

But in public i want to say following.

While making new installation all i care is rebooting to working
operating system.

I.e *i don't care* about entering passwords on middle ground, without
knowing, WTF this installer may do with them, not having comfortable
environment for that _important_ action.

Thus i have silly, empty passwords after installation. Then, i get my
imagination and compose really super-druper passwords for root and users
(that i create myself by script with, IDs i want/have on filesystems, not
by installation process).

Having ssh defaults is just debian's asking -- here i'm, take me, wise
man!

--
-o--=O`C
 #oo'L O
<___=E M


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

Re: RFC: changes to default password strength checks in pam_unix

[Dwayne C. Litzenberger]

On Tue, Sep 04, 2007 at 12:31:15PM +0300, Lars Wirzenius wrote:

I'm sure it does work great. Can you work on making sure [fail2ban] is the
default in lenny if openssh-server is installed?


Keep in mind that, by design, fail2ban opens up a denial-of-service 
vulnerability, especially with the proliferation of NAT routers.


It's not something that should be used without people being aware of what 
it does.


--
Dwayne C. Litzenberger <[EMAIL PROTECTED]>


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

Re: RFC: changes to default password strength checks in pam_unix

[Dwayne C. Litzenberger]

On Mon, Sep 03, 2007 at 05:45:49PM +0300, Lars Wirzenius wrote:

ma, 2007-09-03 kello 08:33 -0600, Wesley J. Landaker kirjoitti:

Especially when the most common response I've seen to a system saying
that a 
password is not long enough is to start adding easily guessable extension 
strings to the password the user already picked, NOT to sit back down and 
think up a better, intrinsicly longer password:


That's true. Ideally, we would replace passwords with a better
authentication system, but I'm not sure that's going to be feasible.


IMHO, user-supplied passwords are not appropriate to use over the Internet, 
because they _will_ be weak.


On most of my boxes, passwords are useless for anything except local 
authentication, and even for that, they aren't used much.


How about a Debian policy that enumerates the specific cases where 
passwords are allowed to be used for authentication, and states that 
password authentication must be disabled by default for everything else?


If you design the system so that it doesn't trust passwords much to begin 
with, you don't have to care about how strong the passwords are.


--
Dwayne C. Litzenberger <[EMAIL PROTECTED]>


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

Re: RFC: changes to default password strength checks in pam_unix

[Roberto C . Sánchez]

On Tue, Sep 04, 2007 at 02:50:25PM -0600, Dwayne C. Litzenberger wrote:
> 
> How about a Debian policy that enumerates the specific cases where 
> passwords are allowed to be used for authentication, and states that 
> password authentication must be disabled by default for everything else?
> 
> If you design the system so that it doesn't trust passwords much to begin 
> with, you don't have to care about how strong the passwords are.
> 
Because not everyone has the luxury of always working from a place where
keys can be effectively managed and used.  Personally, *none* of my
systems allow password logins from the network.  However, that needs to
be a decision for the individual admin.

Think about it.  Someone sets up a box and then heads over to a friend's
house.  He wants to SCP some stuff over.  No password authentication?
Oops.  Too bad.  I don't think that will work without driving away
users.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: RFC: changes to default password strength checks in pam_unix

[John Kelly]

On Tue, 4 Sep 2007 14:50:25 -0600, "Dwayne C. Litzenberger"
<[EMAIL PROTECTED]> wrote:

>On most of my boxes, passwords are useless for anything except local 
>authentication, and even for that, they aren't used much.

>How about a Debian policy that enumerates the specific cases where 
>passwords are allowed to be used for authentication, and states that 
>password authentication must be disabled by default for everything else?

IMO, it's better to leave that policy at a local level, determined by
local admins.  Excessive legislation at a federal level is undesirable
to me.


-- 
Internet service
http://www.isp2dial.com/
 

Re: menu policy & use of doc-base for programming documentation

[Eric Cooper]

On Tue, Sep 04, 2007 at 07:59:44PM +, Frank Küster wrote:
> We have a similar problem with TeX documentation.  In my opinion,
> using menu categories for doc-base might have been a good start, but
> we should definitely extend that now.

Perhaps we should piggyback on the debtags work and have some kind of
tag-based document registration and browsing, rather than trying to
define the One True Hierarchy.

-- 
Eric Cooper e c c @ c m u . e d u


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

Re: libpango update broke iceape synaptic and more

[Steve Kemp]

On Tue Sep 04, 2007 at 11:54:23 -0500, Don wrote:

> I am using "sid" and yesterday my update/upgrade broke iceape, synaptic, and 
> some others.  I've had problems with libpango before, but this one has me 
> stumped.  I don't see anyone else having this problem, so I must conclude 
> something is wrong with my installation.

  I see it too, on my AMD64 system:

  [EMAIL PROTECTED]:~$ firefox 
  /usr/lib/iceweasel/firefox-bin: symbol lookup error: 
/usr/lib/libpangoft2-1.0.so.0: undefined symbol: g_once_init_enter_impl

  Interestingly the symbol is defined:

  [EMAIL PROTECTED]:~$ nm -D /usr/lib/libpangoft2-1.0.so.0 |grep g_once_
   U g_once_init_enter_impl
   U g_once_init_leave

  I ran firefox under strace and I can see the system load and open
 the correct .so so I'm a little stumped too.

  I can't see any open bug reports, so I'd suggest you submit one.
 FWIW I fetched the source and rebuilt it locally, but the problem
 persists..

Steve
--


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

Re: libpango update broke iceape synaptic and more

[Julien Cristau]

On Tue, Sep  4, 2007 at 23:39:46 +0100, Steve Kemp wrote:

>   I see it too, on my AMD64 system:
> 
>   [EMAIL PROTECTED]:~$ firefox 
>   /usr/lib/iceweasel/firefox-bin: symbol lookup error: 
> /usr/lib/libpangoft2-1.0.so.0: undefined symbol: g_once_init_enter_impl
> 
>   Interestingly the symbol is defined:
> 
>   [EMAIL PROTECTED]:~$ nm -D /usr/lib/libpangoft2-1.0.so.0 |grep g_once_
>U g_once_init_enter_impl
>U g_once_init_leave
> 
U means undefined.  That symbol presumably comes from glib.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: libpango update broke iceape synaptic and more

[Steve Kemp]

On Wed Sep 05, 2007 at 00:43:46 +0200, Julien Cristau wrote:
> >   [EMAIL PROTECTED]:~$ firefox 
> >   /usr/lib/iceweasel/firefox-bin: symbol lookup error: 
> > /usr/lib/libpangoft2-1.0.so.0: undefined symbol: g_once_init_enter_impl
> > 
> >   Interestingly the symbol is defined:
> > 
> >   [EMAIL PROTECTED]:~$ nm -D /usr/lib/libpangoft2-1.0.so.0 |grep g_once_
> >U g_once_init_enter_impl
> >U g_once_init_leave
> > 
> U means undefined.  That symbol presumably comes from glib.

  Thanks for the hint.  I've now "solved" the problem.

  Running ldd against the named library I see this:

  libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x2ac8b5c58000)

  That is *incorrect*,  I have the /lib/libglib* file upon my system
 and no idea where it came from!  The correct files are located in 
 /usr/lib/ - archiving /lib/libglib* made the problem go away.

  (This is the second time I've found my sid system having extra
 libraries in /lib.  The first time I thought it was my fault as
 I was working with .rpm files at the time - but nothing like that
 recently.  If anybody has any experience with this type of problem
 I'd love hints on tracking it down ...)

Steve
-- 


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

Re: Why no Opera?

[Gunnar Wolf]

[EMAIL PROTECTED] dijo [Mon, Aug 27, 2007 at 02:46:30PM -0400]:
>
> Hmm, seems odd that it should need testing, runs great on my machine
> and thousands of others. Perhaps we are a little overzealous, no?

Perhaps it should be removed from testing? We cannot do any kind of
security support for it...

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Bug#440881: ITP: kblogger -- kicker-applet for quick blogging

[Raphael Geissert]

Package: wnpp
Severity: wishlist
Owner: Raphael Geissert <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: kblogger
  Version : 0.6.5
  Upstream Author : Christian Weilbach, Antonio Aloisio
* URL : http://kblogger.pwsp.net/
* License : GPL
  Programming Lang: C++
  Description : kicker-applet for quick blogging

KBlogger is a simple to use blogging application for the K Destkop Environment. 
It integrates in KDE 
Kicker for easy and fast blogging. The Interface is very minimalstic and tries 
to provide maximal 
usability for your enjoymnet. Just push to the blog button and start writing.
 By now KBlogger supports two API's which are the MetaWeblog and the Google 
Blogger.

- -- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-a64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG3gyIYy49rUbZzloRAiQDAJ9W4ft8r9gdvi9ybC1m2NOF3811MwCfd+OZ
cvXZhzI1tF6S2hEmpsUkDYE=
=FoIm
-END PGP SIGNATURE-


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

Re: RFC: changes to default password strength checks in pam_unix

[Christian Perrier]

Quoting Joey Hess ([EMAIL PROTECTED]):
> Steve Langasek wrote:
> > Arguably if the consensus is that the default minimum password length should
> > be raised in the users' best interests, we would want to change the
> > makepasswd package's default at the same time.
> 
> And we might also want to make d-i do the same checks, currently it
> enforces no minimum lengths at all..


And, to complete that discussion, we currently have a bug report for
user-setup (the D-I component which deals with root/user creation and
password setting), which suggest to enforce some basic checks of
passwords.

A proposed implementation is in that bug report and Javier Fernandes
Sanguino proposed self to try implementing something stronger.

Given the various advices given in this thread about password strength
enforcement by default, I'm not sure that we will finally implement
this..:-)

But, certainly, at least we could enforce the same pwd length than
PAM.




signature.asc
Description: Digital signature