Is udev's new network naming really as stable as they claim? (was: Re: overriding udev rules)

2013-09-24 Thread peter green 


They are stable as long as the kernel and the hardware do not change too
much; e.g. enabling the "other" graphics card in a hybrid setup
sometimes adds a PCIe bus, so all names shift around.
  
Or adding something like a firewire card which happens to be based on a 
PCIe to PCI bridge chip would also add a bus and therefore has the 
potential for names to shift arround.


The new scheme seems to have the same problem the original kernel scheme 
had but moved one level up. Instead of network names depending on the 
order in which the kernel enumerated network adaptors they now depend on 
the order in which the BIOS enumerated "PCI busses"* Is that an 
improvement over just letting the kernel assign names? is it an 
improvement over debian's scheme?


For servers the answer is probablly yes, servers often have a lot of 
network adaptors, adaptors may be replaced by maintinance personell who 
are different from those setting up the OS and the chances of people 
adding or removing hardware that creates extra PCI busses is pretty low.


For desktops on the other hand i'm inclined to belive the answer is no. 
Desktops rarely have more than one or two network adaptors but they are 
much more likely than servers to have things like graphics cards, 
firewire cards, serial cards etc added or removed which can mess with 
the PCI bus numbers.


* in quotes because on modern hardware a logical PCI bus may or may not 
represent a real PCI bus.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52413f50.9070...@p10link.net

Bug#724492: ITP: kchildlock -- Child computer time restrictor

2013-09-24 Thread Howard Chan 
Package: wnpp
Severity: wishlist
Owner: Howard Chan 

* Package name: kchildlock
  Version : 0.90.4.2
  Upstream Author : Rene Landert 
* URL : http://kchildlock.sourceforge.net
* License : GPL-2+
  Programming Lang: C++
  Description : Child computer time restrictor

 kchildlock restricts the time a children spends on the PC.
 Limits can be specified per day of the week, by lower and
 upper hour limits, max daily usage time, and max weekly
 usage time. Restriction limits can be applied to applications.
 Linux/ KDE4.
 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130924091733.9308.12543.reportbug@smartboyhw-kedubuntu

Verhoog uw productiviteit met efficiënte COMMUNICATIEAPPARATUUR!

2013-09-24 Thread Teleburo 
Indien u dit bericht niet of slecht kunt lezen, 
http://tr1.mp010.net/r5.aspx?GV1=TDGX02N0001AXH001EZIX000QC1CZ&mpvrs=0003028B072376251&cid=
 
volg deze koppeling. 




http://tr1.mp010.net/r5.aspx?GV1=TDGX02N0001AXH001EZIY000QC1CZ&mpvrs=0003028B072376251&cid=
 

http://tr1.mp010.net/r5.aspx?GV1=TDGX02N0001AXH001EZJ4000QC1CZ&mpvrs=0003028B072376251&cid=
 
Verhoog uw productiviteit met efficiënte
COMMUNICATIEAPPARATUUR!


http://tr1.mp010.net/r5.aspx?GV1=TDGX02N0001AXH001EZJQC1CZ&mpvrs=0003028B072376251&cid=
 

http://tr1.mp010.net/r5.aspx?GV1=TDGX02N0001AXH001EZJ1000QC1CZ&mpvrs=0003028B072376251&cid=
 
- - - -  Zowel traditionele telefooncentrales als hosted PBX
- - - -  Zeer gemakkelijke interface, door klant te bewerken
- - - -  Implementatie op meerdere sites zonder meerkost
- - - -Smartphone als binnenpost

http://tr1.mp010.net/r5.aspx?GV1=TDGX02N0001AXH001EZIZ000QC1CZ&mpvrs=0003028B072376251&cid=
 



http://tr1.mp010.net/r5.aspx?GV1=TDGX02N0001AXH001EZJ3000QC1CZ&mpvrs=0003028B072376251&cid=
 

http://tr1.mp010.net/r5.aspx?GV1=TDGX02N0001AXH001EZJ2000QC1CZ&mpvrs=0003028B072376251&cid=
 


http://tr1.mp010.net/r5.aspx?GV1=TDGX02N0001AXH001EZIW000QC1CZ&mpvrs=0003028B072376251&cid=
 



http://tr1.mp010.net/r5.aspx?GV1=TDGX02N0001AXH001EZIV000QC1CZ&mpvrs=0003028B072376251&cid=
 

http://tr1.mp010.net/r5.aspx?GV1=TDGX02N0001AXH001EZJ7000QC1CZ&mpvrs=0003028B072376251&cid=
 

*Bij aankoop van een hosted PBX of een traditionele PBX. 

http://tr1.mp010.net/r5.aspx?GV1=TDGX02N0001AXH001EZJ6000QC1CZ&fguidv5=001AXI&mpvrs=0003028B072376251
 
Volg deze link om niet langer berichten te ontvangen over Teleburo.

http://tr1.mp010.net/r5.aspx?GV1=TDGX02N0001AXH001EZJ5000QC1CZ&fguidv5=0001GX&mpvrs=0003028B072376251
 

Volg deze link om niet langer berichten te ontvangen van vraaguwofferte.

Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing

2013-09-24 Thread Thorsten Glaser 
Kees Cook  debian.org> writes:
> On Sat, Sep 21, 2013 at 02:46:34PM +0200, Bas Wijnen wrote:
> > On Fri, Sep 20, 2013 at 10:12:16PM -0700, Kees Cook wrote:
> > > This is absolutely a bug in glibc. While the spec can say "undefined",
it
> > > is, in fact, not undefined. It worked in a very specific way for over
a

Right, “common law”. It predates the standard.

> > > decade, so that's pretty well defined. ;) The fortify function has no
need
> > > to change it.
> > 
> > I strongly disagree.  If I write a specification for something and an
> > implementation of it, then the specification is what defines the
behavior.  If

But you don’t just write a C99 library! You write a libc for a Unix-ish
system, with POSIX coming into the mix… as well as lots of historic
practice! Using the standard not defining something as excuse to break
historic practice just makes you look bad.

> > Code that does undefined things is buggy, even if it works on some
> > implementation, and no matter how long it has worked.

I totally disagree. Yes, the C99 standard has a lot of Undefined
Behaviour, more than C89 anyway – but why?

> it's a bug to even allow undefined behavior.

I’m calling for a language that is enough like C for us to be able
to reuse existing code, but has no UB, defines signed overflow,
defines bit sizes (no more 36-bit ints), etc.

I think you’d like that too, from a security PoV.

The idea that there were conflicts in the standards committee is
not all that off, or maybe they just couldn’t decide or didn’t
want to or, like GCC developers (who said this publicly!) only
care about benchmark performance because relying on UB enables
some otherwise-unsafe optimisations. But it’s a nightmare and
prevents people from both writing reliable code now *and* using
old code (say, AT&T nroff, from decades back) with modern (other
than tcc and pcc) compilers.

> In a theoretical sense, sure. In this particular case, why bother breaking
> it when it's a trivial 1 line fix? My original approach was to fix it in
> libc and do a mass bug filing. Everyone wins. If we want to reject the

The glibc people decision to return NULL in crypt(3) has led to
several (plural) CVEs in other software, such as cyrus-sasl2 and
xlockmore, already and breaks the GNU CVS testsuite.

I’ve watched them (both upstream and Debian) not care.

(FWIW, musl never returns NULL, and MirBSD libc now also doesn’t,
even not in the very obscure cases where it was historically
acceptable, especially since even the “how to use crypt()” example
in POSIX itself happily dereferences the retval w/o NULL checks.)

I’m with you here, but I think you’re shouting at walls.

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20130924t134453-...@post.gmane.org

Bug#724506: ITP: libcgi-expand-perl -- convert flat hash to nested data using TT2's dot convention

2013-09-24 Thread Vasudev Kamath 
Package: wnpp
Severity: wishlist
Owner: Vasudev Kamath 

* Package name: libcgi-expand-perl
  Version : 2.04
  Upstream Author : Bard Bowman 
* URL : https://metacpan.org/module/CGI::Expand
* License : Artistic or GPL-1+
  on license)
  Programming Lang: Perl
  Description : convert flat hash to nested data using TT2's dot convention

 Converts a CGI query into structured data using a dotted name
 convention similar to TT2.  expand_cgi works with CGI.pm,
 Apache::Request or anything with an appropriate "param" method. Or you
 can use expand_hash directly.
 .
 If you prefer to use a different flattening convention then CGI::Expand
 can be subclassed.
 .

 This is dependency of libcatmandu-perl

-- 
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4  C96B 6C8F 74AE 8770 0B7E


signature.asc
Description: Digital signature

Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing

2013-09-24 Thread Russ Allbery 
Thorsten Glaser  writes:

> The glibc people decision to return NULL in crypt(3) has led to several
> (plural) CVEs in other software, such as cyrus-sasl2 and xlockmore,
> already and breaks the GNU CVS testsuite.

crypt returning NULL transforms various obscure but more serious problems
into a denial of service attack (dereferencing a NULL pointer).  I think
it's movement in the right direction.  Yes, it required changes in the
downstream users to fix handling of a NULL return, but POSIX already said
that a NULL return was possible, so those were existing latent bugs
(consider resource exhaustion errors in the crypt implementation, for
example).  It's a simple failure, as opposed to the more obscure failures
possible with the previous implementation.

This change also sets us up for a possible future where we decide that DES
is sufficiently insecure that we want to refuse to ever use a DES hash.

Your proposed solution on libc-alpha was ingenious, but I think it breaks
the crypt contract in even more serious ways, since it means that crypt
could now return a string matching the disabled password field in
/etc/shadow.  I bet there's at least one program out there that would then
let people authenticate to locked accounts.  It's at least extremely
surprising and not clearly better than returning NULL.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bo3imcj2@windlord.stanford.edu

Re: Roll call for porters of architectures in sid and testing

2013-09-24 Thread Zhang Cong 
Hi,

I am not currently a porter but I would like to be one for the Hurd.

I do some test on QEMU and public Hurd host.

I am familiar with system programming and have some embedded and printer
driver development experience.  I use Linux for 11 year, family with cross
compiling tool chain.

I never contributed to Debian before, I read Debian developer guide and GNU
maintainer guide recently.

I want to focus on system usable issue like GUI  or driver issue and back
to Hurd itself if needed. I also wan't to make system clear for new comer.

I am not a DD/DM

Cong Zhang


2013/9/1 Niels Thykier 

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> As we announced in [LAST-BITS], we would like to get a better idea of
> that status of the ports, to make an informed decision about which
> port can be released with jessie. One of the steps is to get an
> overview of which of the porters are (still) active for each
> port. Once the results from the role-call are in, we will request
> other information about the status of the ports. In the meantime, feel
> free to update and collect info about the ports in the Debian wiki[WIKI].
>
> If you are (or intend to become) an active porter for the lifetime of
> jessie, then please send a signed email explaining your involvement in
> the port to the Release Team  before
> 1st of October 2013. Please explain the level of your involvement in
> the port.
>
> Feel free to use the following template as your reply:
>
> """
>   Hi,
>
>   I am an active porter for the following architectures and I intend
>   to continue this for the lifetime of the jessie release:
>
>   For , I
>   - test (most|all) packages on this architecture
>   - fix toolchain issues
>   - triage arch-specific bugs
>   - fix arch-related bugs
>   - maintain buildds
>   - ...
>
>   
>
>   
> """
>
> Niels, on behalf of the release team
>
> [LAST-BITS]
> http://lists.debian.org/debian-devel-announce/2013/08/msg6.html
>
> [WIKI] https://wiki.debian.org/ArchiveQualification/Jessie
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQIcBAEBCAAGBQJSIu2TAAoJEAVLu599gGRC86EP/j/7FEZ9pxpTEHrBI41GTu6r
> nENS5kAZAuxFQHfYLtKexBcgneGd6cgdmr3cIoh1ZL9lJgXq74X8FL5IbWNqUw9S
> o9UQWpZJiwIIlH4fqSgFVLIphI0DQr7dXI7xcDIm4kl6Fdruo1tGxX8xqL23jzdP
> nQb3jrXv3bj5943MfWeCbODILv2N6qev9VtWeQ6Wmh8PvxRUl7VqgdQaeHtlMsUp
> TQT5fz0cw8gc2amlwlOZxaGDV2C8mHboJIKMEsu79BK4SlFSED9rXn4juFPUnAgG
> uADsMdBBqEIgSMN42cPHQju+KLfJe/+xScmlzzDS/d7aWWs02TibcQ1ZnPi+bcgp
> bd/Wa0lms+Fc2OpcuFle9Lwo+2B+ka1Dd3itm+D0SbmrxoGi6CuMMwydLcQbSJ73
> hHw9HJEIQr2x/ZItNPJrSvvj50rwYXcmFbxtVAwv2pFXfQ37iukYgAaaMvnwpNNJ
> 6dM1coCF9skNkXLO8rkZ+5aupGgjpS9BdKKAEQrPy/aoaW9KNCZrLQeA4C3QySBU
> OcCNBv7taSjVAVNszKtRIQpu2gzFGAV0u9Gj41qW1JzDHYrmAvMyGxrndOxTmaFr
> p05QWgcMsPhNvdHjd6sWLyzJ5NYUKksCPMRgCc0BEd6moIyrt7UFsp2+guJZPBJ0
> pffEJGK2iGtrWmJfElof
> =TUeZ
> -END PGP SIGNATURE-
>
>
> --
> To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/20130901073351.a92862...@thykier.net
>
>

Re: Roll call for porters of architectures in sid and testing

2013-09-24 Thread Nobuhiro Iwamatsu 
Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the jessie release:

For sh4, I
- test packages on this architecture
- triage arch-specific bugs
- fix arch-related bugs
- maintain buildds

For armel and armhf, I
- test packages on this architecture
- triage arch-specific bugs
- fix arch-related bugs

I am a DD.

Best regards,
  Nobuhiro

On Sun,  1 Sep 2013 09:33:51 +0200 (CEST)
ni...@thykier.net (Niels Thykier) wrote:

> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> As we announced in [LAST-BITS], we would like to get a better idea of
> that status of the ports, to make an informed decision about which
> port can be released with jessie. One of the steps is to get an
> overview of which of the porters are (still) active for each
> port. Once the results from the role-call are in, we will request
> other information about the status of the ports. In the meantime, feel
> free to update and collect info about the ports in the Debian wiki[WIKI].
> 
> If you are (or intend to become) an active porter for the lifetime of
> jessie, then please send a signed email explaining your involvement in
> the port to the Release Team  before
> 1st of October 2013. Please explain the level of your involvement in
> the port.
> 
> Feel free to use the following template as your reply:
> 
> """
>   Hi,
>   
>   I am an active porter for the following architectures and I intend
>   to continue this for the lifetime of the jessie release:
> 
>   For , I
>   - test (most|all) packages on this architecture
>   - fix toolchain issues
>   - triage arch-specific bugs
>   - fix arch-related bugs
>   - maintain buildds
>   - ...
>   
>   
>   
>   
> """
> 
> Niels, on behalf of the release team
> 
> [LAST-BITS] 
> http://lists.debian.org/debian-devel-announce/2013/08/msg6.html
> 
> [WIKI] https://wiki.debian.org/ArchiveQualification/Jessie
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.14 (GNU/Linux)
> 
> iQIcBAEBCAAGBQJSIu2TAAoJEAVLu599gGRC86EP/j/7FEZ9pxpTEHrBI41GTu6r
> nENS5kAZAuxFQHfYLtKexBcgneGd6cgdmr3cIoh1ZL9lJgXq74X8FL5IbWNqUw9S
> o9UQWpZJiwIIlH4fqSgFVLIphI0DQr7dXI7xcDIm4kl6Fdruo1tGxX8xqL23jzdP
> nQb3jrXv3bj5943MfWeCbODILv2N6qev9VtWeQ6Wmh8PvxRUl7VqgdQaeHtlMsUp
> TQT5fz0cw8gc2amlwlOZxaGDV2C8mHboJIKMEsu79BK4SlFSED9rXn4juFPUnAgG
> uADsMdBBqEIgSMN42cPHQju+KLfJe/+xScmlzzDS/d7aWWs02TibcQ1ZnPi+bcgp
> bd/Wa0lms+Fc2OpcuFle9Lwo+2B+ka1Dd3itm+D0SbmrxoGi6CuMMwydLcQbSJ73
> hHw9HJEIQr2x/ZItNPJrSvvj50rwYXcmFbxtVAwv2pFXfQ37iukYgAaaMvnwpNNJ
> 6dM1coCF9skNkXLO8rkZ+5aupGgjpS9BdKKAEQrPy/aoaW9KNCZrLQeA4C3QySBU
> OcCNBv7taSjVAVNszKtRIQpu2gzFGAV0u9Gj41qW1JzDHYrmAvMyGxrndOxTmaFr
> p05QWgcMsPhNvdHjd6sWLyzJ5NYUKksCPMRgCc0BEd6moIyrt7UFsp2+guJZPBJ0
> pffEJGK2iGtrWmJfElof
> =TUeZ
> -END PGP SIGNATURE-
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/20130901073351.a92862...@thykier.net


-- 
Nobuhiro Iwamatsu 


pgpeYUirIWXC4.pgp
Description: PGP signature

Bug#724568: ITP: hidapi -- Library for communicating for USB and Bluetooth HID devices

2013-09-24 Thread Scott Talbert 
Package: wnpp
Severity: wishlist
Owner: Scott Talbert 

* Package name: hidapi
  Version : 0.7.0
  Upstream Author : Alan Ott 
* URL : http://www.signal11.us/oss/hidapi/
* License : GPLv3 or BSD
  Programming Lang: C
  Description : Library for communicating for USB and Bluetooth HID devices

HIDAPI is a multi-platform library which allows an application to interface
with USB and Bluetooth HID-class devices on Windows, Linux, FreeBSD, and Mac OS
X.  On Linux, either the hidraw or the libusb back-end can be used.  There are
trade-offs and the functionality supported is slightly different.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130925031815.2085.88406.report...@debian-unstable.techie.net