> 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 ot
> I apologize if my meaning was unclear; it was not meant to be rude. I
> think that looking at only the power of modern CPUs - how long it
> takes to crack a password - misses the point. If you enforce longer
> passwords than people are comfortable with, you get weaker passwords
> (or poor passw
(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 fa
Package: wnpp
Severity: wishlist
Owner: John Sullivan <[EMAIL PROTECTED]>
* Package name: xword
Version : 1.0
Upstream Author : Bill McCloskey <[EMAIL PROTECTED]>
* URL : http://x-word.org
* License : BSD
Programming Lang: Python
Description : GTK progr
On Mon, 03 Sep 2007, 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.
fail2ban is an easy way to do this (for ssh and optionally anything
else that people will try
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
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.
--
Happi
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> If you enforce longer passwords than people are comfortable with, you
> get weaker passwords (or poor password management practices). It's
> the humans that matter, not the machines.
Exactly.
If the system is excessively anal about what passwords i
Package: wnpp
Severity: wishlist
Owner: Daniel Leidert <[EMAIL PROTECTED]>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
* Package name: docbook-xsl-saxon
Version : 1.00
Upstream Author : Norman Walsh and members of the DocBook project.
* URL : http://wiki.docbook.org/
On Mon, Sep 03, 2007 at 07:01:38AM +0200, Christian Perrier wrote:
> > > Given modern processor power availability, I can't think of one;
> >
> > How about modern brain availability? You'll just get a lot of annoyed
> > people changing it back; for example, makepasswd still uses a minimum
> > len
On Mon, Sep 03, 2007 at 07:44:24PM +, Dirk Eddelbuettel wrote:
> Hello mips, anybody home?
The contact address for buildd issues is [EMAIL PROTECTED], not
[EMAIL PROTECTED], in case you haven't tried to former yet.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "u
Package: wnpp
Severity: wishlist
Owner: Sandro Tosi <[EMAIL PROTECTED]>
* Package name: python-pdftools
Version : 0.33
Upstream Author : David Boddie <[EMAIL PROTECTED]>
* URL : http://www.boddie.org.uk/david/Projects/Python/pdftools
* License : LGPL
Descripti
On Mon, Sep 03, 2007 at 09:30:34AM +0200, Petter Reinholdtsen wrote:
> [Steve Langasek]
> > 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've
On Sun, Sep 02, 2007 at 10:29:31PM -0400, Daniel Jacobowitz wrote:
> On Sun, Sep 02, 2007 at 02:39:25PM -0700, Steve Langasek wrote:
> > On Mon, Sep 03, 2007 at 12:04:52AM +0300, Lars Wirzenius wrote:
> > > su, 2007-09-02 kello 12:47 -0700, Steve Langasek kirjoitti:
> > > > Does anyone else have a
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'
Hello mips, anybody home?
I would _really_ appreciate it if someone in charge of the mips builders could
schedule this. Each build should take under a minute -- they only failed
because mips had no matching r-base-core package at the time of the initial
attempt.
Thanks, Dirk
On Tue, Aug 28,
Hi Steve,
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 brok
Michael Banck <[EMAIL PROTECTED]> writes:
> On Sun, Aug 05, 2007 at 12:57:38AM +0200, Samuel Thibault wrote:
>> The bug is that although the mpich-bin package uses
>> update-alternatives --install on postinst for all these files, it uses
>> update-alternatives --remove only on /usr/lib/mpich/bin/m
Sam Hocevar <[EMAIL PROTECTED]> wrote:
> Hello, I would like to gather comments about a proposal I have been
> thinking about during the GPLv2/v3 and GPLv2/CDDL discussions. I have
> finally written down what I have in mind here, and refined it with the
> help of many people on IRC:
> http:/
Tim Hull wrote:
> Anyway, I'm curious - is this still a legitimate consideration within
> Debian?
Yes.
> If it were to be done, it would have to be December/Januaryish (any
That's the plan.
> Thus, one wouldn't HAVE to upgrade, but
> new users and anyone standing to benefit from a new X/kernel
Hi Russ,
Russ Allbery <[EMAIL PROTECTED]> wrote:
> A Mennucc <[EMAIL PROTECTED]> writes:
>
>> BTW, I also encountered a strange "bug" : sometimes the md5sums file
>> contains MD5 of files that are not shipped. This is printed as a warning
>> in my server. If MD5 will become a release goal, this sh
Package: wnpp
Severity: wishlist
Owner: Michael Holzt <[EMAIL PROTECTED]>
* Package name: apparmor
Version : 2.0.2
Upstream Author : Novell/SuSE <[EMAIL PROTECTED]>
* URL : http://en.opensuse.org/Apparmor
* License : GPL
Description : application security
On Sun, Sep 02, 2007 at 10:29:31PM -0400, Daniel Jacobowitz wrote:
> How about modern brain availability? You'll just get a lot of annoyed
> people changing it back; for example, makepasswd still uses a minimum
> length of six.
And pwgen defaults to eight... the length recommended by IETF RFC
408
On Sun, Sep 02, 2007 at 11:55:16PM +0200, Jens Seidel wrote:
> On Sun, Sep 02, 2007 at 10:58:12PM +0200, Frank Lichtenheld wrote:
> > - While DDTP translations are used, the translation of all other
> >strings is mostly broken currently. Should be fixed someday...
>
> Why? Is some kind of i18
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
ma, 2007-09-03 kello 16:04 +0200, Michael Banck kirjoitti:
> On Sun, Aug 05, 2007 at 12:57:38AM +0200, Samuel Thibault wrote:
> > The bug is that although the mpich-bin package uses
> > update-alternatives --install on postinst for all these files, it uses
> > update-alternatives --remove only on /
>> I agree with Bas here: I'm all for removing the Debian deviation from
>> upstream, so please go ahead with that, but raising it further is not
>> necessarily a useful thing to do. I can easily think of a 6-char password
>> that is a lot more difficult to guess than an 8 char one.
>
> Especiall
On Monday 03 September 2007 01:07:15 Thijs Kinkhorst wrote:
> On Mon, September 3, 2007 08:37, Bas Zoetekouw wrote:
> > And what's the rationale to change the minimum length to 8? It won't
> > help security, as people who pick weak passwords now, will still pick
> > weak, but longer, passwords.
>
Hi,
On Sun, Aug 05, 2007 at 12:57:38AM +0200, Samuel Thibault wrote:
> The bug is that although the mpich-bin package uses
> update-alternatives --install on postinst for all these files, it uses
> update-alternatives --remove only on /usr/lib/mpich/bin/mpirun, leaving
> a bunch of dangling symlin
On Sat, Aug 04, 2007 at 07:17:59PM +0200, Sam Hocevar <[EMAIL PROTECTED]> wrote:
>Hello, I would like to gather comments about a proposal I have been
> thinking about during the GPLv2/v3 and GPLv2/CDDL discussions. I have
> finally written down what I have in mind here, and refined it with the
Package: wnpp
Severity: wishlist
Owner: Oliver Korff <[EMAIL PROTECTED]>
* Package name: tourney-manager
Version : 20070820
Upstream Author : Holger Ruckdeschel <[EMAIL PROTECTED]>
* URL :http://www.hoicher.de/hoichess/tourney_manager/index.html
* License : GPL
Hi,
On Mon, Sep 03, 2007 at 02:14:47PM +0100, Luis Matos wrote:
> this is meant for users to use not-in-backports situation, like testing
> newer software.
As Romain suggested already, a chroot is much better suited for that kind of
testing.
Cheers,
Sebastian
--
Sebastian "tokkee" Harl +++ Gnu
Seg, 2007-09-03 às 09:05 -0400, Roberto C. Sánchez escreveu:
> On Mon, Sep 03, 2007 at 01:09:14PM +0100, Luis Matos wrote:
> >
> > how about the development of tool on we could:
> >
> > - add the sid repos to sources.list
> > - with a simple command download every needed source package
> > (de
Seg, 2007-09-03 às 14:46 +0200, Sebastian Harl escreveu:
> Hi Luis,
>
> On Mon, Sep 03, 2007 at 01:09:14PM +0100, Luis Matos wrote:
> > how about the development of tool on we could:
> >
> > - add the sid repos to sources.list
>
> This should be done manually, it only has to be done once anywa
On Mon, Sep 03, 2007 at 01:09:14PM +0100, Luis Matos wrote:
>
> how about the development of tool on we could:
>
> - add the sid repos to sources.list
> - with a simple command download every needed source package
> (dependencies)
> - build the packages
> - install all the packages.
>
A fe
Hi Luis,
On Mon, Sep 03, 2007 at 01:09:14PM +0100, Luis Matos wrote:
> how about the development of tool on we could:
>
> - add the sid repos to sources.list
This should be done manually, it only has to be done once anyway.
> - with a simple command download every needed source package
> (de
Le Monday 03 September 2007 14:09:14 Luis Matos, vous avez écrit :
> is this doable?
Honnestly, it seems difficult and dangerous to automate that way.
when you backport a package there are plenty of reasons you should take care
of dependencies, in particular when there's a major upgrade at some
Hello there ...
i had an idea that probably someone already had ...
i am using etch and i use anjuta for c/c++ development.
i would try anjuta 2.2 because it seems to be a huge improvement over
1.2.4. To do that i have to put the sid sources to sources.list,
re-compile some stuff and then instal
Уважаемые коллеги!
2 - 3 апреля 2008 г. в Харькове состоится 5-я Международная
конференция «Сотрудничество для решения проблемы отходов».
Подробности – http://www.waste.com.ua/cooperation или по запросу.
Конечный срок представления материалов для публикации – 1 декаб
Hi,
On Sun Sep 02, 2007 at 17:46:56 -0400, Tim Hull wrote:
> Does this mean anything with regards to how backports will operate? I'm
> just curious, as you probably know from my past posts that I'm quite
> interested in stable release updates beyond simple security updates...
As member of the S
Tim Hull schrieb am Sonntag, den 02. September 2007:
Hi Tim,
> Does this mean anything with regards to how backports will operate? I'm
> just curious, as you probably know from my past posts that I'm quite
> interested in stable release updates beyond simple security updates...
Speaking as a bac
ma, 2007-09-03 kello 09:30 +0200, Petter Reinholdtsen kirjoitti:
> I've been told that the schools using Debian Edu in lower grades pick
> very simple and short passwords for the kids, and this will become
> harder if the minimum lenght is increased. Thought it was best to
> bring that up publicly
[Steve Langasek]
> 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've been told that the schools using Debian Edu in lower grades pick
very simple an
On Mon, September 3, 2007 08:37, Bas Zoetekouw wrote:
> And what's the rationale to change the minimum length to 8? It won't
> help security, as people who pick weak passwords now, will still pick weak,
> but longer, passwords.
I agree with Bas here: I'm all for removing the Debian deviation from
44 matches
Mail list logo