Re: deb-ice -- violating the GPL since 2007-08-14
Robert Edmonds wrote: > "deb-ice" is a custom Debian distribution, described in [0] and available from > [1]. It appears to be a preseeded Debian 4.0 i386 business card ISO built > using a web-based tool called LinuxCOE[2], and the aggregator has attempted to > place the entire work under a license[3] which appears to be the GPLv2 with > the > string "GNU GENERAL PUBLIC LICENSE" stripped out. Ouch! It appears to me that deb-ice is not a Debian project, though. Therefore, it may be worth to take this to the deb-ice developer(s) instead of the Debian project. Otherwise debian-curiosa seems to be a proper list for such comments. Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
DUG: Debian User Groups, and their status.
Hi, I've noticed that there is: http://wiki.debian.org/LocalGroups and added Japan to the list. I think it would be better served if it were linked from www.debian.org, or placed under www.debian.org. Am I missing something? regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP: libmath-pari-perl
Package: wnpp Severity: wishlist Owner: Deepak Tripathi <[EMAIL PROTECTED]> * Package name : libmath-pari-perl Version : 2.010709 Upstream Author :Ilya Zakharevich |* URL : http://search.cpan.org/~ilyaz/Math-Pari-2.010709/ * License : Perl License Programming Lang : Perl Description: This package is a Perl interface to famous library PARI for numerical/scientific/number-theoretic calculations. It allows use of most PARI functions as Perl functions, and (almost) seamless merging of PARI and Perl data. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440544: ITP: easyspice -- A graphical frontend to the Spice simulator
Package: wnpp Severity: wishlist Owner: "Gudjon I. Gudjonsson" <[EMAIL PROTECTED]> * Package name: easyspice Version : 0.6.7 Upstream Author : Jean-Marc Routoure <[EMAIL PROTECTED]> * URL : http://easy-spice.sourceforge.net * License : GPL Programming Lang: C Description : A graphical frontend to the Spice simulator Easyspice is a graphical frontend for the electrical circuit simulator Spice. It is by default connected to the geda package and ngspice but can be used as a frontend for other spice simulators programs as well. . Homepage: http://easy-spice.sourceforge.net -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-1-amd64 (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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440553: ITP: gspiceui -- A graphical user interface for gnucap and ngspice
Package: wnpp Severity: wishlist Owner: "Gudjon I. Gudjonsson" <[EMAIL PROTECTED]> * Package name: gspiceui Version : 0.9.33 Upstream Author : Name Mike Waters <[EMAIL PROTECTED]> * URL : http://www.geda.seul.org/tools/gspiceui * License : GPL Programming Lang: C++ Description : A graphical user interface for gnucap and ngspice Gspiceui is a graphichal user interface for the two freely available electronic circuit engines: GNU-Cap and Ng-Spice Current features are: * Import gschem schematic files using gentlist. * Load and parse circuit description (net list) files. * Provides a GUI interface for GNU-Cap OP, DC, AC and Transient analyses and generates appropriate simulator commands based on user input. * Provides a GUI interface for Ng-Spice DC, AC and Transient analyses and generates appropriate simulator commands based on user input. * The raw output may be viewed for any processes initiated by gspiceui. * Formatting of simulator output so that it may be plotted using gwave . Homepage: http://www.geda.seul.org/tools/gspiceui/ -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-1-amd64 (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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
"Etch and a half" ( was Re: Bugfix/hardware support updates to stable releases?)
Hi all, The idea (mentioned in the prior thread) of having an "Etch and a half" release with an updated X/kernel/installer sounds EXACTLY like what I was hinting at. Backports are great, but having a supported, Debian-tested release that Debian can give to users with new/exotic hardware (which has better support in newer kernels/X releases) would be much better. I've been wrestling with Etch this summer on my MacBook (first generation!), and such a release would probably eliminate 99% of my complaints. Many Debian users are probably in the same boat - they don't mind having an old GNOME/Emacs/coreutils, but do mind being stuck with a kernel/X/installer that doesn't fully support their hardware. Anyway, I'm curious - is this still a legitimate consideration within Debian? If it were to be done, it would have to be December/Januaryish (any later and it would be too close to Lenny, unless of course Lenny is late). I figure that this would be a new "branch" - much in the same sense as sarge, etch, lenny, and sid are. Thus, one wouldn't HAVE to upgrade, but new users and anyone standing to benefit from a new X/kernel (and possibly some other bugfixes) would want to consider using the new "etch and a half". I think this idea would definitely benefit Debian - more people would be able to use it, and it would remain quite stable while still supporting the latest hardware. Obviously, there are issues with the whole plan. For one, Debian would effectively have one more development branch - at least while any such "and-a-half" releases are developed. Effectively, this may end up looking like FreeBSD if such releases ever became common - albeit with less updates to the "-stable" branch. Furthermore, that would mean one more branch to support with security updates, upgrades to lenny (or lenny+1 if a "lenny-and a half" or a "lenny-and-two-thirds" are ever made), etc. These are all legitimate concerns. However, I think it's worth consideration - in my mind, this would fix Debian's greatest flaw in a way that's much better than the Ubuntuish "we must release the full distro every 6 months" approach. I'm curious to hear what everybody thinks regarding this whole concept, and I'd love to see Debian seriously consider this. Tim P.S. I know I am not a Debian developer, and I don't even have a package in the archive. I totally understand if you feel like it's a bit overreaching for me to bring things like this up. Rest assured that I appreciate everything Debian does, and I don't mean to detract from that AT ALL. I will say that I'd definitely test any "and-a-half" release if this ever came to fruition, and I'd work to help make it work out as I could. Heck, I've already been trying to work on making my own "and-a-half" to make Etch work fully on my MacBook :)
RFC: changes to default password strength checks in pam_unix
Hi folks, 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. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440565: ITP: cereal -- automated, logged serial terminal management system
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor <[EMAIL PROTECTED]> * Package name: cereal Version : 0.11 Upstream Author : Jameson Rollins <[EMAIL PROTECTED]> and Daniel Kahn Gillmor <[EMAIL PROTECTED]> * URL : http://cmrg.fifthhorseman.net/wiki/cereal * License : GPLv3 Programming Lang: Bash Description : automated, logged serial terminal management system cereal provides an easy way to set up and maintain automated, timestamped logs of serial lines, while simultaneously allowing end users to access them. cereal can control an arbitrary number of logged lines, and each will be independently monitored. . Direct access to the monitored lines is allowed only to a specific user (who doesn't necessarily otherwise have access to the direct serial line), but logs can be made available to any group. Logs are rotated automatically and their total space can be limited in size. . Homepage: http://cmrg.fifthhorseman.net/wiki/cereal - I'm not a debian developer, so i'll need someone to upload this. The packaging is ready, though, and has been tested over the last couple of versions on a handful of production machines. Regards, --dkg -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: block 438885 with 440574
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.9.26 > block 438885 with 440574 Bug#440574: memlockd postinst starts twice, doesn't use invoke-rc.d Bug#438885: Mass bug filing: must use invoke-rc.d Was blocked by: 341413 341415 348259 348263 353660 367722 367725 367727 367729 367730 367731 367732 367733 367734 367737 367740 367745 367753 367754 367755 367759 367760 367762 375183 Blocking bugs of 438885 added: 440574 > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- 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
su, 2007-09-02 kello 12:47 -0700, Steve Langasek kirjoitti: > 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. What's the justification of not using a minimum password length of 8? -- Crappy tools are not worth it. Find or make better ones. -- 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
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 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. > What's the justification of not using a minimum password length of 8? Given modern processor power availability, I can't think of one; but I would prefer to deal with this in two parts, first establishing whether we have a good reason to use a /lower/ default than upstream, and then discussing with upstream whether that default should be raised. The upstream default of 6 has been around for at least 5 years, possibly as long as a decade; and the code in question is inactive when pam_unix is linked to cracklib, which I think most distributors other than Debian are doing (we confine the use of libcracklib to the separate pam_cracklib module, to keep cracklib out of base); so there probably isn't any modern justification for this default at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Backports now appearing on debian.org package listings?
When browsing debian.org, I came across something rather interesting... http://packages.debian.org/etch-backports/ Evidently, all of the backports.org backports are now listed on the debian.org packages listing. They are still on the backports.org servers and not on the debian.org mirrors, but they do indeed appear on the Debian website. Debian-volatile also appears there as well, as well as the unofficial etch-m68k. 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... Tim
Re: Backports now appearing on debian.org package listings?
On Sun, Sep 02, 2007 at 09:46:56PM +, Tim Hull wrote: > When browsing debian.org, I came across something rather interesting... > > http://packages.debian.org/etch-backports/ see last debian-devel-announce@ mail. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpekUTT8JD33.pgp Description: PGP signature
Re: packages.debian.org updated
Hi, 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. great! Thanks a lot. > Some known regressions: > > - While DDTP translations are used, the translation of all other >strings is mostly broken currently. Should be fixed someday... Why? Is some kind of i18n process missing or are translations just outdated? Feel free to ask on debian-i18n for updates. > The new code can be found in my git repository. More information at > http://packages.debian.org/about/ Does this mean http://cvs.debian.org/packages/?root=webwml is obsolete or do you want to merge it? Jens -- 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
On Sun, Sep 02, 2007 at 02:39:25PM -0700, Steve Langasek wrote: > > The upstream default of 6 has been around for at least 5 years, possibly as > long as a decade; and the code in question is inactive when pam_unix is > linked to cracklib, which I think most distributors other than Debian are > doing (we confine the use of libcracklib to the separate pam_cracklib > module, to keep cracklib out of base); so there probably isn't any modern > justification for this default at all. > Just curious, what is the rationale for wanting to keep cracklib out of base? 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
On Sun, Sep 02, 2007 at 07:38:23PM -0400, Roberto C. Sánchez wrote: > On Sun, Sep 02, 2007 at 02:39:25PM -0700, Steve Langasek wrote: > > The upstream default of 6 has been around for at least 5 years, possibly as > > long as a decade; and the code in question is inactive when pam_unix is > > linked to cracklib, which I think most distributors other than Debian are > > doing (we confine the use of libcracklib to the separate pam_cracklib > > module, to keep cracklib out of base); so there probably isn't any modern > > justification for this default at all. > Just curious, what is the rationale for wanting to keep cracklib out of > base? Size and complexity. Adding libpam-cracklib to base would be a 2MB increase in the size of a minimal Debian system on i386, and add 5 packages to the list of what has to be installed before the user can do something as simple as set the initial root password. Also, in terms of modularity, I don't think it makes sense for pam_unix to link to cracklib anyway when we have a separate pam_cracklib module for that (whether it's in a separate package or not). I also think that enabling cracklib password checking is probably not a reasonable default for single-user systems, because however much we might like users to use secure passwords, the hassle of disabling cracklib if the user disagrees with us on this point is enough to make this a very unpleasant user experience. Maybe if and when we have better up-front documentation of what the password requirements are we could consider this as a default, but I don't want users to go through the experience of hitting five different password strength rules, one-by-one, in the ever-more-frustrating process of trying to set a password. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- 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
On Sun, Sep 02, 2007 at 05:20:42PM -0700, Steve Langasek wrote: > On Sun, Sep 02, 2007 at 07:38:23PM -0400, Roberto C. Sánchez wrote: > > > Just curious, what is the rationale for wanting to keep cracklib out of > > base? > > Size and complexity. Adding libpam-cracklib to base would be a 2MB increase > in the size of a minimal Debian system on i386, and add 5 packages to the > list of what has to be installed before the user can do something as simple > as set the initial root password. Also, in terms of modularity, I don't > think it makes sense for pam_unix to link to cracklib anyway when we have a > separate pam_cracklib module for that (whether it's in a separate package or > not). > > I also think that enabling cracklib password checking is probably not a > reasonable default for single-user systems, because however much we might > like users to use secure passwords, the hassle of disabling cracklib if the > user disagrees with us on this point is enough to make this a very > unpleasant user experience. Maybe if and when we have better up-front > documentation of what the password requirements are we could consider this > as a default, but I don't want users to go through the experience of hitting > five different password strength rules, one-by-one, in the > ever-more-frustrating process of trying to set a password. > OK. Good to know. Thanks, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: conflicting gssapi libraries
http://linux-nfs.org/pipermail/nfsv4/2007-September/006695.html The following message belongs to the thread listed above. >Date: Sun, 2 Sep 2007 18:57:24 -0400 >From: Kevin Coffman <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED], Russ Allbery <[EMAIL PROTECTED]> >Cc: [EMAIL PROTECTED] >Subject: Re: conflict between heimdal and umich gssapi library and their >consequences > >On 9/1/07, Russ Allbery <[EMAIL PROTECTED]> wrote: >> >>I'm fairly sure that for right now Debian is just living with the problem >>and conflicting the libraries. That makes Heimdal almost unusable in >>Debian since the UMich GSS-API indirection layer gets pulled in by the >>NFSv4 support, which is part of standard. >> >>I'm still of the opinion that UMich was at fault here and they need to >>rename their GSS-API library to something else. Heimdal was using that >>library name first, and regardless of how much more "generic" they think >>their indirection layer is, taking a shared library name that's already in >>use is frankly rather rude. Picking a different SONAME version to start >>with clearly isn't sufficient, as we now see. > >I regret any inconvenience our libgssapi library has caused. We used >the obvious name and had no malicious intent. > >I will rename our library to libgssglue which will require a change in >librpcsecgss and will require nfs-utils to be reconfigured and >recompiled (no source changes required). I will put out new versions >on Tuesday. I'll package libgssglue and change nfs-utils to depend on libgssglue. >K.C. >___ >NFSv4 mailing list >[EMAIL PROTECTED] >http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 On Wed, Aug 15, 2007 at 12:51:13PM +1000, Brian May wrote: >So in summary, what is the verdict? > >I am inclined to add a non-versioned conflicts for now, as I suspect >it might be a while before this can be solved in a better way. > >Also: No, I don't want to maintain a patch in Heimdal that renames the >library. > >If upstream could be convinced to rename the library that would be OK >though. Upstream decided to rename the UMich libgssapi library. >-- >Brian May <[EMAIL PROTECTED]> Best Regards, Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: conflicting gssapi libraries
On Mon, Sep 03, 2007 at 12:03:47PM +1000, Anibal Monsalve Salazar wrote:
>I'll package libgssglue and change nfs-utils to depend on libgssglue.
The {build-,}dependencies of both librpcsecgss and libgssapi are:
source package librpcsecgss
depends:
nfs-common librpcsecgss3
nfs-kernel-server librpcsecgss3
build-depends:
nfs-utils librpcsecgss-dev
source package libgssapi
depends:
nfs-common libgssapi2
nfs-kernel-server libgssapi2
build-depends:
fetchmail libgssapi-dev
librpcsecgss libgssapi-dev
nfs-utils libgssapi-dev (>= 0.11)
Best Regards,
Aníbal Monsalve Salazar
--
http://v7w.com/anibal
signature.asc
Description: Digital signature
Re: RFC: changes to default password strength checks in pam_unix
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 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. > > > What's the justification of not using a minimum password length of 8? > > 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 length of six. -- Daniel Jacobowitz CodeSourcery -- 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
> > 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 > length of six. My weak English makes me think your comment is rude. Please excuse me then if this is not. I don't really understand the need for turning your comment this way, which indeed doesn't make your point clear, whether you agree or disagree with the idea of default enforcement of 8 characters length for passwords. It seems you disagree, but don't really give a rationale for it except "some other programs we have in Debian default to 6 chars". Am I right? (BTW, this "makepasswd" doesn't seem to be isntalled by default) signature.asc Description: Digital signature
Bug#440607: ITP: steam-powered -- Valve's steam game content delivery system
Package: wnpp Severity: wishlist Owner: Michael Gilbert <[EMAIL PROTECTED]> * Package name: steam-powered Version : 6 Upstream Author : Michael Gilbert * URL : no website * License : GPL Programming Lang: shell Description : Valve's steam game content delivery system This package is a wrapper that makes it easy to install and run Valve's Steam program via wine. The intent will be for this package to be a part of the contrib archive. A preliminary version of the package has been uploaded to debian-mentors for review and testing, [1]. There has already been some interesting discussion on the mentors list. Please read [2], [3], and [4] to get up to speed. I am looking forward to the discussion and getting this package added to the archive. Steam (www.steampowered.com) is a game content delivery system developed by Valve software (http://www.valvesoftware.com). This is a windows application, which is supported on your Debian system via wine (http://www.winehq.org). Not all steam games work at this time, but many do. Games that work very well include half-life, counter-strike, half-life 2, and counter-strike: source. More information about steam can be found at http://www.steampowered.com. [1] http://mentors.debian.net/debian/pool/contrib/s/steam-powered/ [2] http://lists.debian.org/debian-mentors/2007/08/msg00592.html [3] http://lists.debian.org/debian-mentors/2007/08/msg00599.html [4] http://lists.debian.org/debian-mentors/2007/08/msg00601.html Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) 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
On Mon, Sep 03, 2007 at 07:01:38AM +0200, Christian Perrier wrote: > It seems you disagree, but don't really give a rationale for it except > "some other programs we have in Debian default to 6 chars". Am I right? > > (BTW, this "makepasswd" doesn't seem to be isntalled by default) And can also be easily patched (I bet). Also, as a makepasswd user, I often have to invoke it as "makepasswd --minchars 8" since several passwords I have to generate require a minimum of 8 characters anyway. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: RFC: changes to default password strength checks in pam_unix
Hi Christian! You wrote: > I don't really understand the need for turning your comment this way, > which indeed doesn't make your point clear, whether you agree or > disagree with the idea of default enforcement of 8 characters length > for passwords. > > It seems you disagree, but don't really give a rationale for it except > "some other programs we have in Debian default to 6 chars". Am I right? 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. -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
