Re: vision: easily move all my data and config to a new machine

[Helmut Grohne]

On Sun, Jun 23, 2013 at 09:28:07PM +0100, Philip Hands wrote:
> If etckeeper were to check in the unmodified versions of the packaged
> conffiles in a branch called 'dpkg-dist' (or whatever) then it would be
> trivial to do a diff.
> 
> Presumably it would be possible to do this in one of the hook scripts.

This is known as #542048. Could you expand your implementation plan on
that bug? I don't yet quite see how to implement it.

Helmut


-- 
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/2013062507.GA7364@localhost.localdomain

download of source packages alarmed clamav

[Harald Dunkel]

Hi folks,

I am running a transparent http proxy integrated with clamav.
Problem: If I run "apt-get source pymilter", then I get

# apt-get source pymilter
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'pymilter' packaging is maintained in the 'Svn' version control system 
at:
svn://svn.debian.org/python-modules/packages/pymilter/trunk/
Need to get 100 kB of source archives.
Get:1 http://ftp.de.debian.org/debian/ squeeze/main pymilter 0.9.3-2 (dsc) 
[1318 B]
Err http://ftp.de.debian.org/debian/ squeeze/main pymilter 0.9.3-2 (tar)
  500  Missing Content-Length
Get:2 http://ftp.de.debian.org/debian/ squeeze/main pymilter 0.9.3-2 (diff) 
[2756 B]
Fetched 4074 B in 2s (1614 B/s)
Failed to fetch 
http://ftp.de.debian.org/debian/pool/main/p/pymilter/pymilter_0.9.3.orig.tar.gz 
 500  Missing Content-Length
E: Failed to fetch some archives.


Using a web browser for download I see a message generated by
my proxy:

Virus Alarm

The URL
http://ftp.de.debian.org/debian/pool/main/p/pymilter/pymilter_0.9.3.orig.tar.gz

contains the following virus:
Exploit.IFrame.Gen(4c4d77c2301e1afcbf40714b924aff6d:96362)

Access denied.
Powered by SquidClamAv 5.4


The same happens for a few other source packages as well.


I doubt that sending a virus complies to the DFSG, so the question
is whether these source packages have been compromised?


Harri


-- 
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/51c93d1c.9030...@aixigo.de

Re: download of source packages alarmed clamav

[Timo Juhani Lindfors]

Harald Dunkel  writes:
> I doubt that sending a virus complies to the DFSG, so the question
> is whether these source packages have been compromised?

The test/ directory in pymilter_0.9.3.orig.tar.gz contains some sample
viruses on purpose. I can't comment on other source packages since you
didn't name them.


-- 
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/84ip12tz0c@sauna.l.org

Re: download of source packages alarmed clamav

[Marius Gavrilescu]

Forgot to list-reply.

On Tue, Jun 25, 2013 at 08:47:56AM +0200, Harald Dunkel wrote:
> I doubt that sending a virus complies to the DFSG, so the question
> is whether these source packages have been compromised?

That package contains a directory named test/ with emails with spam, viruses
and similar. This might have caused the clamav warning.

-- 
Marius Gavrilescu


signature.asc
Description: Digital signature

Re: download of source packages alarmed clamav

[Marius Gavrilescu]

On Tue, Jun 25, 2013 at 09:52:26AM +0200, Harald Dunkel wrote:
> Its not a warning. The download failed.

Yes, I should have said failure. Anyway, the probable cause
is the existence of emails with viruses as tests in the package.
-- 
Marius Gavrilescu

signature.asc
Description: Digital signature

Re: download of source packages alarmed clamav

[Harald Dunkel]

On Tue, 25 Jun 2013 10:46:23 +0300
Marius Gavrilescu  wrote:
> 
> That package contains a directory named test/ with emails with spam, viruses
> and similar. This might have caused the clamav warning.
> 

Its not a warning. The download failed.


Regards
Harri


-- 
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/20130625095226.604b1...@dpcl082.ac.aixigo.de

Re: download of source packages alarmed clamav

[Marius Gavrilescu]

On Tue, Jun 25, 2013 at 10:19:46AM +0200, Harald Dunkel wrote:
> These are real-life viruses that should not be distributed 
> using Debian's FTP server (IMHO). 

Even if they wre real, they would be "real-life" MS Windows viruses in
emails in a debian package. For someone to get "infected" they would have
to run MS Windows, download a debian package, unpack it, open a file named
"virusN" in an email viewer and run the attached file.

However, as far as I know they're not actual viruses, they're just made to
look like them (i.e. they contain the signatures, but not the harmful code). 

Therefore they're harmless.
-- 
Marius Gavrilescu
(science-kids) In some rocks you can find the fossil footprints of fishes.


signature.asc
Description: Digital signature

Re: download of source packages alarmed clamav

[Harald Dunkel]

On Tue, 25 Jun 2013 10:54:53 +0300
Marius Gavrilescu  wrote:

> On Tue, Jun 25, 2013 at 09:52:26AM +0200, Harald Dunkel wrote:
> > Its not a warning. The download failed.
> 
> Yes, I should have said failure. Anyway, the probable cause
> is the existence of emails with viruses as tests in the package.

These are real-life viruses that should not be distributed 
using Debian's FTP server (IMHO). 

Eicar is a test virus.


-- 
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/20130625101946.12b98...@dpcl082.ac.aixigo.de

Bug#714058: ITP: cc65 -- Cross compiler and toolchain for 6502-based systems

[John Paul Adrian Glaubitz]

Package: wnpp
Severity: wishlist
Owner: John Paul Adrian Glaubitz 

* Package name: cc65
  Version : 2.13.3
  Upstream Author : Ullrich von Bassewitz 
* URL : http://www.cc65.org/
* License : zlib and non-free
  Programming Lang: C
  Description : Cross compiler and toolchain for 6502-based systems

cc65 is a complete cross development package for 6502-based systems. It
features a C compiler plus all the standard binutils one would expect
from a toolchain, including an archiver, an assembler, a disassembler,
a linker, an object file dump utility and even a 6502 CPU simulator. A
resource compiler for the GEOS operating system as well as various
support libraries are also part of the distribution.

The following targets are supported:

* Commodore C64
* GEOS operating system on C64
* Commodore C128
* Commodore C16, C116 and Plus/4
* Commodore P500
* Commodore 600/700 family
* Apple II
* Atari 8 bit family
* Oric Atmos
* Nintendo NES
* Watara Supervision
* Atari Lynx

Both direct library support (startup/initialization code) as well as
support libraries are supplied for these targets. These libraries
include support for the following APIs:

* conio (text-based console I/O, non-scrolling)
* dio (block-oriented disk I/O)
* em (expanded memory, allowing to address >64K RAM)
* joystick (support for joystick devices)
* mouse (mouse support and other absolute input devices)
* serial (serial I/O)
* tgi (2D graphics primitives)

The cc65 compiler was originally written by John R. Dunning and comes
with an open source license which is not DFSG-compliant since it forbids
to charge for the distribution of a copy of the software. cc65 is therefore
going to be part of the non-free distribution.


-- 
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/20130625110412.15053.51198.report...@z6.physik.fu-berlin.de

Bug#714062: ITP: libstring-compare-constanttime-perl -- module for protecting string comparison from timing attacks

[Alexandre Mestiashvili]

Package: wnpp
Severity: wishlist
Owner: Alexandre Mestiashvili 

* Package name: libstring-compare-constanttime-perl
  Version : 0.300
  Upstream Author : Doug Hoyte
* URL : https://metacpan.org/module/String::Compare::ConstantTime
* License : Artistic or GPL-1
  Programming Lang: Perl
  Description : module for protecting string comparison from timing attacks

String::Compare::ConstantTime provides one function, equals(), which takes two 
strings of the same lenght as arguments.
It will return true if they are string-wise identical and false otherwise, 
just like eq. However, comparing any two differing strings will take a fixed 
amount of time, unlike eq.


-- 
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/20130625112344.1594.9706.report...@lxcsid.biotec.tu-dresden.de

Re: download of source packages alarmed clamav

[Scott Kitterman]

Harald Dunkel  wrote:

>On Tue, 25 Jun 2013 10:54:53 +0300
>Marius Gavrilescu  wrote:
>
>> On Tue, Jun 25, 2013 at 09:52:26AM +0200, Harald Dunkel wrote:
>> > Its not a warning. The download failed.
>> 
>> Yes, I should have said failure. Anyway, the probable cause
>> is the existence of emails with viruses as tests in the package.
>
>These are real-life viruses that should not be distributed 
>using Debian's FTP server (IMHO). 

This comes up periodically. They aren't real.

Scott K


-- 
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/c437fc8f-649c-4d32-b0e2-77c98f1ac...@email.android.com

Re: download of source packages alarmed clamav

[Scott Kitterman]

Marius Gavrilescu  wrote:

>On Tue, Jun 25, 2013 at 10:19:46AM +0200, Harald Dunkel wrote:
>> These are real-life viruses that should not be distributed 
>> using Debian's FTP server (IMHO). 
>
>Even if they wre real, they would be "real-life" MS Windows viruses in
>emails in a debian package. For someone to get "infected" they would
>have
>to run MS Windows, download a debian package, unpack it, open a file
>named
>"virusN" in an email viewer and run the attached file.
>
>However, as far as I know they're not actual viruses, they're just made
>to
>look like them (i.e. they contain the signatures, but not the harmful
>code). 
>
>Therefore they're harmless.

Correct. 

Scott K


-- 
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/3f9897e5-b6cd-4129-b78c-06d2b137f...@email.android.com

Re: download of source packages alarmed clamav

[Darac Marjal]

On Tue, Jun 25, 2013 at 08:04:00AM -0400, Scott Kitterman wrote:
> 
> 
> Harald Dunkel  wrote:
> 
> >On Tue, 25 Jun 2013 10:54:53 +0300
> >Marius Gavrilescu  wrote:
> >
> >> On Tue, Jun 25, 2013 at 09:52:26AM +0200, Harald Dunkel wrote:
> >> > Its not a warning. The download failed.
> >> 
> >> Yes, I should have said failure. Anyway, the probable cause
> >> is the existence of emails with viruses as tests in the package.
> >
> >These are real-life viruses that should not be distributed 
> >using Debian's FTP server (IMHO). 
> 
> This comes up periodically. They aren't real.

It would appear they're real enough to trigger clamav's detection, which
was the problem the OP was having.


signature.asc
Description: Digital signature

Bug#714076: ITP: core -- intuitive network emulator that interacts with real nets

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 

* Package name: core
  Version : 4.6
  Upstream Author : Boeing Company, by Jeffrey M. Ahrenholz 

* URL : http://cs.itd.nrl.navy.mil/work/core
* License : Simplified BSD
  Programming Lang: C, C++, Python, Tcl/Tk
  Description : intuitive network emulator that interacts with real nets

 The Common Open Research Emulator (CORE) is a tool for emulating
 networks on one or more machines. You can connect these emulated
 networks to live networks.
 .
 CORE consists of a GUI for drawing topologies of lightweight virtual
 machines, and Python modules for scripting network emulation.
 .
 Key features:
 .
   1. Network lab in a box
- Efficient and scalable
- Easy-to-use GUI canvas
- Centralized configuration and control
   2. Runs applications and protocols without modifying them
   3. Real-time connection to live networks
- Hardware-in-the-loop
- Distributed with multiple COREs
   4. Highly customizable


-- 
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/20130625124823.6730.76762.report...@libra.gabcmt.eb.mil.br

Re: Reporting 1.2K crashes

[Alexandre Rebert]

Hi,

Thanks for all the feedback and comments. I tried to address all them below.

> The crash.sh script seems to set LD_LIBRARY_PATH.  Is that actually
> needed?  I'd prefer something that doesn't need something like that,
> since being able to crash apps if you load a broken library isn't very
> hard.

The purpose of the custom environment is to run the program with the
same environment as it was set up when the program was analyzed with
Mayhem. This is not necessary to reproduce most crashes however. I
will remove the *LIBRARY_PATH from the environment, and re-confirm the
crashes without it.

> Since you're already running this under gdb, would you mind attaching a
> full backtrace with debug symbols installed too?

That is a good idea, but I'm afraid I cannot easily get the debug
symbols. As far as I know, binaries from debian packages do not
contain symbols. Additionally, for 91% of the packages where we found
a crash, there isn't any associated -dbg package. It should be easy
however for a developer that has a program with debug symbols to
generate the backtrace. I could include a backtrace without symbols,
but that does not seem particularly useful. What do you think?

> Would it be possible to initially publish all the bug reports on your
> web site under some random URL and then mail that to the maintainer
> with a clearly indicated date when they will be made public?

Good point. I will mail the maintainer the bug reports, and give them
1 week to prepare before submitting the bug to the Debian BTS.

> Can one also access, even before you go and file bugs, information for other
> packages? I cannot actually find any reports for the package listed in the
> dd-list under my name in your Packages, Runs, nor Programs pages. (And the 
> fact
> that the reported package is a transitional package does make this a little
> suspicious.)

The reports are not public yet. Since you are a developer included in
dd-list, we will send you an email containing the crash information
for the programs you are developing. You will receive the email 1 week
before the crash is submitted to the BTS. Does that sound reasonable?

> Have you considered adding Mayhem to Debian so
> that it may be added to the usual battery of tests some developers run
> before uploads?

We are considering offering Mayhem as a web service as opposed to
adding it to Debian.  I'd love to see Mayhem check every package
release automatically, so that (some) crashes are detected and fixed
before the binary being released. Mayhem is however not open source,
so I'm not sure people will be willing to make use of it. Let me know
if you think otherwise, and we'll discuss how we can set this up.

> Are you aware of the firehose project and format that Fedora and some
> Debian folks have been working on? It is a standard machine-readable
> format for defect finding tools to report their findings so that sites
> like the Debian PTS can report those to developers.

I was not aware of firehose. This is a cool project. It would be great
to have a similar system for dynamic analysis of binaries, that allows
non-free software to submit reports. Even though Mayhem is not open
source, we still want to improve Debian's security and stability :)

Thanks,
The Mayhem Team
Cylab, Carnegie Mellon Univeristy


-- 
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/caf1as2gcoduwuafkrwxp2hk1-jjze65rhomws+jczzmcdzo...@mail.gmail.com

Re: Reporting 1.2K crashes

[Michael Tautschnig]

Hi Alexandre,

(Just replying regarding the point I had raised.)

[...]
> > Can one also access, even before you go and file bugs, information for other
> > packages? I cannot actually find any reports for the package listed in the
> > dd-list under my name in your Packages, Runs, nor Programs pages. (And the 
> > fact
> > that the reported package is a transitional package does make this a little
> > suspicious.)
> 
> The reports are not public yet. Since you are a developer included in
> dd-list, we will send you an email containing the crash information
> for the programs you are developing. You will receive the email 1 week
> before the crash is submitted to the BTS. Does that sound reasonable?
> 
[...]

Sounds great, yes!

Looking forward to receiving detailed information,
Michael



pgpk83WzPlWWU.pgp
Description: PGP signature

Re: Reporting 1.2K crashes

[Paul Wise]

On Tue, Jun 25, 2013 at 10:54 PM, Alexandre Rebert wrote:

> The reports are not public yet. Since you are a developer included in
> dd-list, we will send you an email containing the crash information
> for the programs you are developing. You will receive the email 1 week
> before the crash is submitted to the BTS. Does that sound reasonable?

I have one minor package (mancala) in the dd-list, please send me the
info needed to reproduce the crash.

> We are considering offering Mayhem as a web service as opposed to
> adding it to Debian.  I'd love to see Mayhem check every package
> release automatically, so that (some) crashes are detected and fixed
> before the binary being released. Mayhem is however not open source,
> so I'm not sure people will be willing to make use of it. Let me know
> if you think otherwise, and we'll discuss how we can set this up.

It is a shame that you are not willing to open the project.

Since it isn't open, people would probably not be willing to run it
but probably would look at the results on a web service if they were
useful.

> I was not aware of firehose. This is a cool project. It would be great
> to have a similar system for dynamic analysis of binaries, that allows
> non-free software to submit reports. Even though Mayhem is not open
> source, we still want to improve Debian's security and stability :)

I expect the format could be used by Mayhem and Debian's QA
infrastructure could consume it and point developers at relevant pages
on your site.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6H_EnOJDWR7WYgiQZr+L++mbo48J=svfxtctbuiwy6...@mail.gmail.com

Re: Reporting 1.2K crashes

[Marc Haber]

On Tue, 25 Jun 2013 01:28:10 -0400, Alexandre Rebert
 wrote:
>I am a security researcher at Carnegie Mellon University, and my team
>has found thousands of crashes in binaries downloaded from debian
>wheeze packages. After contacting ow...@bugs.debian.org, Don Armstrong
>advised us to contact you before submitting ~1.2K bug reports to the
>Debian BTS using mainto...@bugs.debian.org (to avoid spamming
>debian-bugs-dist).

Will you also check Debian unstable? It is much easier to have a
package in unstable fixed, and I suspect that not every crash you find
will be a security relevant one.

Additionally, I guess that the vast majority of crahes you have found
will be upstream bugs which the Debian maintainer would have to
forward upstream. Will you take efforts to report these bugs to
upstream as well?

Will you check distributions other than Debian, and how will you make
sure that the upstreams are no swamped with identical bug reports from
each of their downstream distributions?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1urvk2-qf...@swivel.zugschlus.de

Hardening Flags for sg3-utils

[Ritesh Raj Sarraf]

Hi,

Following the Hardening wiki, I have build-dep the hardening-includes
package and enabled the hardening flags as follows :

rrs@zan:/var/tmp/sg3-utils (build)$ cat debian/rules
#!/usr/bin/make -f
# debian/rules file for the sg3-utils package

# This has to be exported to make some magic below work.
export DH_OPTIONS

include /usr/share/hardening-includes/hardening.make

CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS)
CFLAGS:=$(shell dpkg-buildflags --get CFLAGS)
CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS)
LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS)


But still, the hardening-check tool reports this:

rrs@zan:/var/tmp/Debian-Build/Result$ hardening-check /usr/bin/sg_inq
/usr/bin/sg_inq:
 Position Independent Executable: no, normal executable!
 Stack protected: no, not found!
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: no, not found!
 Immediate binding: no, not found!

any suggestion on what could have gone wrong?


Looking at the build log, I don't see the hardening flags being honored:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I ../include
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -W -g -O2 -c
sg_pt_linux.c -o sg_pt_linux.o >/dev/null 2>&1
/bin/bash ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
-I..-I ../include -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall
-W -g -O2 -c -o sg_io_linux.lo sg_io_linux.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I ../include
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -W -g -O2 -c
sg_io_linux.c  -fPIC -DPIC -o .libs/sg_io_linux.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I ../include
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -W -g -O2 -c
sg_io_linux.c -o sg_io_linux.o >/dev/null 2>&1



If I bump the debhelper version to > 9, I do see the correct build flags.

-- 
Given the large number of mailing lists I follow, I request you to CC me
in replies for quicker response




signature.asc
Description: OpenPGP digital signature

Re: Hardening Flags for sg3-utils

[Nick Andrik]

Would it be that you need this?

DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/buildflags.mk

--
=Do-
N.AND


2013/6/25 Ritesh Raj Sarraf :
> Hi,
>
> Following the Hardening wiki, I have build-dep the hardening-includes
> package and enabled the hardening flags as follows :
>
> rrs@zan:/var/tmp/sg3-utils (build)$ cat debian/rules
> #!/usr/bin/make -f
> # debian/rules file for the sg3-utils package
>
> # This has to be exported to make some magic below work.
> export DH_OPTIONS
>
> include /usr/share/hardening-includes/hardening.make
>
> CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS)
> CFLAGS:=$(shell dpkg-buildflags --get CFLAGS)
> CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS)
> LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS)
>
>
> But still, the hardening-check tool reports this:
>
> rrs@zan:/var/tmp/Debian-Build/Result$ hardening-check /usr/bin/sg_inq
> /usr/bin/sg_inq:
>  Position Independent Executable: no, normal executable!
>  Stack protected: no, not found!
>  Fortify Source functions: no, only unprotected functions found!
>  Read-only relocations: no, not found!
>  Immediate binding: no, not found!
>
> any suggestion on what could have gone wrong?
>
>
> Looking at the build log, I don't see the hardening flags being honored:
>
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I ../include
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -W -g -O2 -c
> sg_pt_linux.c -o sg_pt_linux.o >/dev/null 2>&1
> /bin/bash ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
> -I..-I ../include -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall
> -W -g -O2 -c -o sg_io_linux.lo sg_io_linux.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I ../include
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -W -g -O2 -c
> sg_io_linux.c  -fPIC -DPIC -o .libs/sg_io_linux.o
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I ../include
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -W -g -O2 -c
> sg_io_linux.c -o sg_io_linux.o >/dev/null 2>&1
>
>
>
> If I bump the debhelper version to > 9, I do see the correct build flags.
>
> --
> Given the large number of mailing lists I follow, I request you to CC me
> in replies for quicker response
>
>


-- 
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/cann5kotv8sfomaef34tai_fhpc4dn0tan_w18bsthoxpqzk...@mail.gmail.com

Re: Hardening Flags for sg3-utils

[Nick Andrik]

Or probably this section for older debhelper:
http://wiki.debian.org/HardeningWalkthrough#Older_debhelper

--
=Do-
N.AND


-- 
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/cann5kou9mxgmf6c7ufpytni+wuwom1ugefutj_muu5p0zd4...@mail.gmail.com

Re: Reporting 1.2K crashes

[Lisandro Damián Nicanor Pérez Meyer]

On Tuesday 25 June 2013 10:54:21 Alexandre Rebert wrote:
> Hi,
[snip]
> > Would it be possible to initially publish all the bug reports on your
> > web site under some random URL and then mail that to the maintainer
> > with a clearly indicated date when they will be made public?
> 
> Good point. I will mail the maintainer the bug reports, and give them
> 1 week to prepare before submitting the bug to the Debian BTS.

That's not too much time in Debian standards, saddly. I would say *at least* 
two weeks.

[snip]

> Even though Mayhem is not open
> source, 

Too bad. In that way we can not be sure if the testing is correct other if the 
crash is really reproducible.

-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Hardening Flags for sg3-utils

[Steve Langasek]

On Tue, Jun 25, 2013 at 09:40:33PM +0530, Ritesh Raj Sarraf wrote:
> Following the Hardening wiki, I have build-dep the hardening-includes
> package and enabled the hardening flags as follows :



> If I bump the debhelper version to > 9, I do see the correct build flags.

So, why don't you just do this, which is the preferred way to enable
hardening now anyway?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Reporting 1.2K crashes

[Didier 'OdyX' Raboud]

Hi

Le mardi, 25 juin 2013 07.28:10, Alexandre Rebert a écrit :
> I am a security researcher at Carnegie Mellon University, and my team
> has found thousands of crashes in binaries downloaded from debian
> wheeze packages. After contacting ow...@bugs.debian.org, Don
> Armstrong advised us to contact you before submitting ~1.2K bug
> reports to the Debian BTS using mainto...@bugs.debian.org (to avoid
> spamming debian-bugs-dist).

Without diminishing the value of bugreports against our stable release, 
I would be more interested in such reports against the software material 
for our future stable; aka software from unstable; did you have such 
plans in mind?

Cheers,
OdyX


--
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/201306251736.31409.o...@debian.org

Re: Reporting 1.2K crashes

[Alexandre Rebert]

> Without diminishing the value of bugreports against our stable release,
> I would be more interested in such reports against the software material
> for our future stable; aka software from unstable; did you have such
> plans in mind?

That's a good point that has been raised by other people as well. To
address it, we re-ran all the crashes on debian unstable. This means
that all crashes, that will be reported, have been confirmed on the
latest packages from debian unstable.

Thanks,
The Mayhem Team
Cylab, Carnegie Mellon Univeristy

On Tue, Jun 25, 2013 at 11:36 AM, Didier 'OdyX' Raboud  wrote:
> Hi
>
> Le mardi, 25 juin 2013 07.28:10, Alexandre Rebert a écrit :
>> I am a security researcher at Carnegie Mellon University, and my team
>> has found thousands of crashes in binaries downloaded from debian
>> wheeze packages. After contacting ow...@bugs.debian.org, Don
>> Armstrong advised us to contact you before submitting ~1.2K bug
>> reports to the Debian BTS using mainto...@bugs.debian.org (to avoid
>> spamming debian-bugs-dist).
>
> Without diminishing the value of bugreports against our stable release,
> I would be more interested in such reports against the software material
> for our future stable; aka software from unstable; did you have such
> plans in mind?
>
> Cheers,
> OdyX


--
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/caf1as2hdluaqdwkdpb7ealgexmwyubzmaz1ybjbsp-cs0mn...@mail.gmail.com

Re: download of source packages alarmed clamav

[Austin English]

On Tue, Jun 25, 2013 at 5:05 AM, Scott Kitterman  wrote:
>
>
> Marius Gavrilescu  wrote:
>
>>On Tue, Jun 25, 2013 at 10:19:46AM +0200, Harald Dunkel wrote:
>>> These are real-life viruses that should not be distributed
>>> using Debian's FTP server (IMHO).
>>
>>Even if they wre real, they would be "real-life" MS Windows viruses in
>>emails in a debian package. For someone to get "infected" they would
>>have
>>to run MS Windows, download a debian package, unpack it, open a file
>>named
>>"virusN" in an email viewer and run the attached file.
>>
>>However, as far as I know they're not actual viruses, they're just made
>>to
>>look like them (i.e. they contain the signatures, but not the harmful
>>code).
>>
>>Therefore they're harmless.
>
> Correct.
>
> Scott K

FYI, some Windows viruses work under Wine (which can do whatever your
normal user can do, unless you're using AppArmor or something similar
to restrict it).

--
-Austin


-- 
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/CACC5Q1egjmC1xGGGSJEt+N_wksqzC8fJyu=f0dy1ivfmnsx...@mail.gmail.com

Re: Reporting 1.2K crashes

[Alexandre Rebert]

Hi,

On Tue, Jun 25, 2013 at 11:38 AM, Marc Haber
 wrote:
> Will you also check Debian unstable? It is much easier to have a
> package in unstable fixed, and I suspect that not every crash you find
> will be a security relevant one.

We actually already did :) We re-ran all the crashes on debian
unstable. This means that all the crashes we are going to report have
been confirmed on the latest packages from debian unstable.

> Additionally, I guess that the vast majority of crahes you have found
> will be upstream bugs which the Debian maintainer would have to
> forward upstream. Will you take efforts to report these bugs to
> upstream as well?

Yes. Bugs will be reported upstream first. After two weeks, we will
re-ran the crashes on the latest packages from Debian unstable.
Hopefully, the upstream developers will had time to update packages
with a fix. If the crash still exists, then we will go ahead and
submit a report to the Debian BTS.

> Will you check distributions other than Debian, and how will you make
> sure that the upstreams are no swamped with identical bug reports from
> each of their downstream distributions?

We might check distributions other than Debian in the near future,
and, as you pointed out, we need to be careful not to report duplicate
bugs. Avoiding duplicate reports has been one of our main goal. That
is why we are reporting only one bug per binary, and at most 5 crashes
per package. We are still thinking about how to minimize duplicate
reports across distributions. One idea would be to limit the number of
"open" bug report to 1 per upstream. When the bug is marked as fixed,
we analyze the patched binary with Mayhem, and potentially report a
new bug if a crash is found.

Thanks,
The Mayhem Team
Cylab, Carnegie Mellon Univeristy


-- 
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/caf1as2jtkkam+y2bhpjwkkqpwawgwf4dz7l9wpowfbspqnu...@mail.gmail.com

Re: Hardening Flags for sg3-utils

[Ritesh Raj Sarraf]

On Tuesday 25 June 2013 09:47 PM, Nick Andrik wrote:
> Would it be that you need this?
>
> DPKG_EXPORT_BUILDFLAGS = 1
> include /usr/share/dpkg/buildflags.mk
>
> --
> =Do-
> N.AND
>

Don't know what was wrong. Maybe just the lack of sleep. Your suggestion
works. Thank you.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System




signature.asc
Description: OpenPGP digital signature

Re: download of source packages alarmed clamav

[Peter Samuelson]

> On Tue, Jun 25, 2013 at 08:04:00AM -0400, Scott Kitterman wrote:
> > This comes up periodically. They aren't real.

[Darac Marjal]
> It would appear they're real enough to trigger clamav's detection,
> which was the problem the OP was having.

Yes.  It is not really a fixable problem.  The test files intentionally
contain material whose purpose is to trigger a virus scanner.  That is
their entire point.  The fact that they do in fact trigger a virus
scanner is unfortunate in this case, but it is a straightforward
consequence and there probably isn't much you can do about it (except
of course to not use a virus scanner while downloading virus scanning
test data).

The EICAR string is all very well, but doesn't solve this problem.
Either virus scanners treat EICAR just like any real virus, alerting
and/or blocking stuff, or they treat it as a special case.  If the
formert, you haven't solved anything.  If the latter, then by the
nature of it being a special case, EICAR alone is not sufficient test
coverage for virus scanning functionality.

Peter


-- 
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/20130625181639.gd13...@p12n.org

Re: Reporting 1.2K crashes

[Alexandre Rebert]

Hi,

On Tue, Jun 25, 2013 at 2:03 PM, Dmitrijs Ledkovs
 wrote:
> From Ubuntu point of view, we'd also be interested in a similar
> analysis. Unlike Debian we provide automatically generated packages
> with debug symbols.
> Similar to debian, we would most interested for development series to
> be tested, currently saucy. At least main (~3000 packages) or universe
> as well (total size than ~ same as Debian)

It's great to see some interest from other distributions. We would
love to run Mayhem on Ubuntu binaries as well. I'm wondering how
different Debian and Ubuntu packages are though (forgive my
ignorance).

There are some issues (pointed out by Marc Harber [1]) about identical
bugs being reported bugs by multiple distributions that we need to
consider as well. Feel free to contact me directly so that we can talk
about this in more details.

Thanks,
The Mayhem Team
Cylab, Carnegie Mellon Univeristy

[1] http://lists.debian.org/debian-devel/2013/06/msg00742.html


-- 
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/CAF1AS2hMbWt0xH9X=xbrxwshp9b-tpfxh+bjsh4l2jbdhxg...@mail.gmail.com

Re: download of source packages alarmed clamav

[Russ Allbery]

Darac Marjal  writes:
> On Tue, Jun 25, 2013 at 08:04:00AM -0400, Scott Kitterman wrote:

>>> These are real-life viruses that should not be distributed using
>>> Debian's FTP server (IMHO).

>> This comes up periodically. They aren't real.

> It would appear they're real enough to trigger clamav's detection, which
> was the problem the OP was having.

Given that the whole point of those files is to test clamav, I would hope
that they would trigger clamav's detection.  If not, that would be a bug
in clamav, no?

-- 
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/87zjuem3ok@windlord.stanford.edu

Re: Reporting 1.2K crashes

[Russ Allbery]

Marc Haber  writes:

> Will you also check Debian unstable? It is much easier to have a package
> in unstable fixed, and I suspect that not every crash you find will be a
> security relevant one.

I suspect most of them won't be, actually, or at least will be difficult
to exploit.  A lot of command-line binaries that are only ever run by a
regular user aren't particularly well-hardened against things like corrupt
configuration files or weird command-line options, but usually those
problems aren't really exploitable except under very artificial
situations.

Still, it's a robustness bug and I'm very happy to see them reported and
fixed.

-- 
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/87vc52m3kj@windlord.stanford.edu

Re: Reporting 1.2K crashes

[Dmitrijs Ledkovs]

On 25 June 2013 19:21, Alexandre Rebert  wrote:
> Hi,
>
> On Tue, Jun 25, 2013 at 2:03 PM, Dmitrijs Ledkovs
>  wrote:
>> From Ubuntu point of view, we'd also be interested in a similar
>> analysis. Unlike Debian we provide automatically generated packages
>> with debug symbols.
>> Similar to debian, we would most interested for development series to
>> be tested, currently saucy. At least main (~3000 packages) or universe
>> as well (total size than ~ same as Debian)
>
> It's great to see some interest from other distributions. We would
> love to run Mayhem on Ubuntu binaries as well. I'm wondering how
> different Debian and Ubuntu packages are though (forgive my
> ignorance).
>
> There are some issues (pointed out by Marc Harber [1]) about identical
> bugs being reported bugs by multiple distributions that we need to
> consider as well. Feel free to contact me directly so that we can talk
> about this in more details.
>

There is a set of packages that are unique to debian and unique to ubuntu.
Toolchain is slightly different, w.r.t. to security and hardening
options (but that difference is becoming smaller)
There are packagesets that are ahead or behind debian.
Overall scanning ubuntu main should be small amount of packages and
capture majority of above distro differentiating divergences.

Regards,

Dmitrijs.


-- 
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/CANBHLUjA_c_xYrahzhHwdJr=nfkejxsleogptcpjdamkj7h...@mail.gmail.com

Re: download of source packages alarmed clamav

[Jakub Wilk]

* Scott Kitterman , 2013-06-25, 08:04:
These are real-life viruses that should not be distributed using 
Debian's FTP server (IMHO).

This comes up periodically. They aren't real.


I hope so!

Do we even have any real viruses that are DFSG-free?

--
Jakub Wilk


--
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/20130625185344.ga5...@jwilk.net

Re: Reporting 1.2K crashes

[Pau Garcia i Quiles]

Hello,

Is it possible to use/download Mayhem from somewhere?


On Tue, Jun 25, 2013 at 7:28 AM, Alexandre Rebert <
alexandre.reb...@gmail.com> wrote:

We found the bugs using Mayhem [1], an automatic bug finding system
> that we've been developing in David Brumley's research lab for a
> couple of years. We recently ran Mayhem on almost all ELF binaries of
> Debian Wheezy (~23K binaries) [2], and it reported thousands of
> crashes.
>

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: Reporting 1.2K crashes

[Tollef Fog Heen]

]] Alexandre Rebert 

> Hi,
> 
> Thanks for all the feedback and comments. I tried to address all them below.
> 
> > The crash.sh script seems to set LD_LIBRARY_PATH.  Is that actually
> > needed?  I'd prefer something that doesn't need something like that,
> > since being able to crash apps if you load a broken library isn't very
> > hard.
> 
> The purpose of the custom environment is to run the program with the
> same environment as it was set up when the program was analyzed with
> Mayhem. This is not necessary to reproduce most crashes however. I
> will remove the *LIBRARY_PATH from the environment, and re-confirm the
> crashes without it.

Thanks.

> > Since you're already running this under gdb, would you mind attaching a
> > full backtrace with debug symbols installed too?
> 
> That is a good idea, but I'm afraid I cannot easily get the debug
> symbols. As far as I know, binaries from debian packages do not
> contain symbols. Additionally, for 91% of the packages where we found
> a crash, there isn't any associated -dbg package. It should be easy
> however for a developer that has a program with debug symbols to
> generate the backtrace. I could include a backtrace without symbols,
> but that does not seem particularly useful. What do you think?

If you can install -dbg packages if they are available and then include
the backtrace, that'd be sufficient.  I imagine just installing all -dbg
packages from the same source package should be a suitable approach in
most cases.

Thanks,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/m2fvw6c5n2@rahvafeir.err.no

Bug#714110: ITP: python-memprof -- memory profiler for Python

[Javi Merino]

Package: wnpp
Severity: wishlist
Owner: Javi Merino 

* Package name: python-memprof
  Version : 0.2.2
  Upstream Author : Jose M. Dana 
* URL : http://jmdana.github.io/memprof/
* License : GPLv3
  Programming Lang: Python
  Description : memory profiler for Python

memprof logs and plots the memory usage of all the variables during
the execution of the decorated methods.


-- 
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/20130625204434.16242.48754.reportbug@einstein.local

Re: Reporting 1.2K crashes

[Marc Haber]

On Tue, 25 Jun 2013 14:06:42 -0400, Alexandre Rebert
 wrote:
>On Tue, Jun 25, 2013 at 11:38 AM, Marc Haber
> wrote:
>> Additionally, I guess that the vast majority of crahes you have found
>> will be upstream bugs which the Debian maintainer would have to
>> forward upstream. Will you take efforts to report these bugs to
>> upstream as well?
>
>Yes. Bugs will be reported upstream first. After two weeks, we will
>re-ran the crashes on the latest packages from Debian unstable.
>Hopefully, the upstream developers will had time to update packages
>with a fix. If the crash still exists, then we will go ahead and
>submit a report to the Debian BTS.

I understand. But two weeks might be a bit too short for the majority
of those crashes. Many upstream authors don't get paid for working on
their software.

Thanks for your verbose answer.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1urapg-0002b2...@swivel.zugschlus.de

Re: Reporting 1.2K crashes

[Marc Haber]

On Tue, 25 Jun 2013 11:46:04 -0700, Russ Allbery 
wrote:
>Marc Haber  writes:
>
>> Will you also check Debian unstable? It is much easier to have a package
>> in unstable fixed, and I suspect that not every crash you find will be a
>> security relevant one.
>
>I suspect most of them won't be, actually, or at least will be difficult
>to exploit.  A lot of command-line binaries that are only ever run by a
>regular user aren't particularly well-hardened against things like corrupt
>configuration files or weird command-line options, but usually those
>problems aren't really exploitable except under very artificial
>situations.
>
>Still, it's a robustness bug and I'm very happy to see them reported and
>fixed.

I fully agree with you. Actually, this is the reason why I think that
such reports would make more sense against unstable since we are
unlikely to fix an unexploitable crash bug in stable, and upstreams
are unlikely to care about crashes in software they released a year
ago.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1uraqr-0002be...@swivel.zugschlus.de

Re: Reporting 1.2K crashes

[Alexandre Rebert]

Hi,

> I understand. But two weeks might be a bit too short for the majority
> of those crashes. Many upstream authors don't get paid for working on
> their software.

I first want to clarify the purpose of the two-week delay to make sure
we are on the same page.We do not expect upstream developers to fix
the bugs in that time frame. The two-week delay allows developers to
assess the bugs' seriousness. If the bug is security critical and two
weeks is too short to patch it, they can contact us and we'll gladly
delay the public disclosure further. If the bug is not security
critical however, then I do not see any reason not to submit it on the
BTS.

If you believe that the delay is too short nonetheless, we can
definitely extend it. What would be a reasonable of time for
developers to review the bugs then?

Thanks,
The Mayhem Team
Cylab, Carnegie Mellon Univeristy


-- 
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/caf1as2i313wfuuzpbwwoe6t+eukrn8vm-hmvodrwgh4e0qq...@mail.gmail.com

Bug#714118: ITP: php-composer -- Dependency Manager for PHP

[ar]

Package: wnpp
Severity: wishlist
Owner: ar 

* Package name: php-composer
  Version : 1.0.0-alpha7
  Upstream Author : Nils Adermann , Jordi Boggiano 

* URL : http://getcomposer.org/
* License : MIT
  Programming Lang: PHP
  Description : Dependency Manager for PHP

Composer is a tool for dependency management in PHP, similar to Bundler
(Ruby), npm (Node), etc. It allows developers to declare the libraries a
PHP project depends on and it installs them in the project tree.


-- 
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/20130625223241.20244.75314.report...@x12yad.0.lon.net.0x0b.net

Bug#714120: ITP: libjs-chosen -- select box enhancer for jQuery and Protoype

[David Prévot]

Package: wnpp
Severity: wishlist
Owner: David Prévot 

* Package name: libjs-chosen
  Version : 0.9.11
  Upstream Author : Patrick Filler 
* URL : http://harvesthq.github.io/chosen/
* License : Expat
  Programming Lang: JavaScript
  Description : select box enhancer for jQuery and Protoype

 Chosen is a JavaScript plugin that makes long, unwieldy select boxes
 more user-friendly.


The purpose is to use it as a third party in other packages like
owncloud. As such, I intend to maintain it under the Debian JavaScript
Maintainers umbrella.

Regards

David


signature.asc
Description: Digital signature

Hope to use ticket system for maintaining/requesting cdn.debian.net

[Yasuhiro Araki]

Hi all,
I am developing and operating cdn.debian.net.

I would like to discuss about using the ticket system for maintaining
cdn.debian.net.

I think BTS and/or github are the best way. Could you show your idea?

1) BTS of debian: It is better way of tracking by debian way.

However, cdn.debian.net is not an official debian service. Is that possible?

2) github: I would like to open repository of codes at github in a few
days.

I love to use git. Unfortunately, it is difficult to use alioth because
alioth's interface is not enough to access under strict firewall..(for my
environment.)

3) Other ways?


Background:
I am afraid that sometime I missed to receive emails which somebody notify
trouble and a request for cdn.debian.net.

As you know, cdn.debian.net is a widely distributed system.
Reporting Volunteer is very important.

P.S.
Now I have been following plan to add new function to cdn.debian.net as
follows,
1. User reporting interface (describe in this mail.)
2. Support CNAME mirror servers. Guide to CNAME for some servers and CDN
services.
3. Location accuracy improvement. Now cdn.d.n use MaxMind's country
database. I would like to use City database or more accurate GeoIP database.
4.  support.



P.S.2
I hope to attend f2f meeting at debconf2013.
But unfortunately I cannot attend it.
If teleconf, and other way meetings are open, I would like to join from
Japan.

Thanks all.

-- 
ARAKI Yasuhiro
a...@debian.org

Re: download of source packages alarmed clamav

[Chow Loong Jin]

On Tue, Jun 25, 2013 at 11:04:40AM -0700, Austin English wrote:
> [...]
> FYI, some Windows viruses work under Wine (which can do whatever your
> normal user can do, unless you're using AppArmor or something similar
> to restrict it).

That's not entirely true -- a Windows-based keylogger wouldn't really work with
Wine -- you'd need X-specific code for that. I reckon talking to user-accessible
UNIX sockets would probably also be out of the question. But anything that
involves snooping around the filesystem would probably work, but only if it
knows where to look (z: is mapped to / by default) inside a Wine environment.

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Python 3.3 Status?

[Nikolaus Rath]

Hi,

I'm a bit confused about the current status of Python 3.3. If I'm not
mistaken, python3.3 is available in unstable, but not included in the
py3versions output, so none of the packaged python3-* extension modules
include .so's for Python 3.3.

Can someone tell me if that's deliberate or accidental, and if/when it's
going to change?

(I asked Matthias (the python3.3 maintainer AFAIU) about this a little
while ago but got no answer, so I'm trying my luck here.)


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
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/87bo6t37d4@vostro.rath.org

Re: Python 3.3 Status?

[Scott Kitterman]

On Tuesday, June 25, 2013 07:59:03 PM Nikolaus Rath wrote:
> Hi,
> 
> I'm a bit confused about the current status of Python 3.3. If I'm not
> mistaken, python3.3 is available in unstable, but not included in the
> py3versions output, so none of the packaged python3-* extension modules
> include .so's for Python 3.3.
> 
> Can someone tell me if that's deliberate or accidental, and if/when it's
> going to change?
> 
> (I asked Matthias (the python3.3 maintainer AFAIU) about this a little
> while ago but got no answer, so I'm trying my luck here.)

It is supported, but not the default python3 yet:

$ py3versions -d
python3.2
$ py3versions -s
python3.2 python3.3

We are close to ready to make the switch:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708536

This work is being tracked on the debian-python mailing list.  You can join us 
there for further discussions and see the list archive for additional details.

Scott K


-- 
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/1847156.kJCCpqdbgt@scott-latitude-e6320

Re: download of source packages alarmed clamav

[Joey Hess]

Russ Allbery wrote:
> Given that the whole point of those files is to test clamav, I would hope
> that they would trigger clamav's detection.  If not, that would be a bug
> in clamav, no?

However, the point of the pymilter source package is not to test clamav,
it's to distribute the source to pymilter. Falsely triggering virus scanners
does not help it achieve this aim.

So, the tarball could be fixed to rot-13 the virus files stored in it,
and re-rotate them when the test suite is run. (If virus scanners
perhaps try rot-13, then instead encrypt the viruses with a key included
in the source package, but that's probably overkill.)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: download of source packages alarmed clamav

[Russ Allbery]

Joey Hess  writes:

> So, the tarball could be fixed to rot-13 the virus files stored in it,
> and re-rotate them when the test suite is run. (If virus scanners
> perhaps try rot-13, then instead encrypt the viruses with a key included
> in the source package, but that's probably overkill.)

That's a good idea.  If ROT-13 isn't sufficient, a simple XOR cipher that
could be hacked together in a few lines of Python doubtless would be,
without the complexity of real encryption.  But I bet ROT-13 would do it.

-- 
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/87obato17h@windlord.stanford.edu

Re: download of source packages alarmed clamav

[Scott Kitterman]

On Tuesday, June 25, 2013 11:06:26 PM Russ Allbery wrote:
> Joey Hess  writes:
> > So, the tarball could be fixed to rot-13 the virus files stored in it,
> > and re-rotate them when the test suite is run. (If virus scanners
> > perhaps try rot-13, then instead encrypt the viruses with a key included
> > in the source package, but that's probably overkill.)
> 
> That's a good idea.  If ROT-13 isn't sufficient, a simple XOR cipher that
> could be hacked together in a few lines of Python doubtless would be,
> without the complexity of real encryption.  But I bet ROT-13 would do it.

The first time this came up, I discussed it with upstream.  Their view is that 
it's part of (for testing) the example milters that are shipped either in 
pymilter or pymilter-milters and so they think it's appropriate to ship it.  
In the past, I've concluded it wasn't something worth changing what upstream 
shipped to 'fix'.

It's not there to test clamav.  IIRC, there's a heuristic test in one of the 
sample milters that would detect it directly.  Anyone who doesn't like the 
fact that clamav has a false positive on this file might want to consider 
sending it to them.  On clamav.net there's a process for submitting false 
positives.

Scott K


-- 
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/1487871.NEvMSKbTmG@scott-latitude-e6320

Bug#714134: ITP: python-django-discover-runner -- alternative Django test runner

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-django-discover-runner
  Version : 1.0
  Upstream Author : Jannis Leidel 
* URL : https://pypi.python.org/pypi/django-discover-runner
* License : BSD
  Programming Lang: Python
  Description : alternative Django test runner

 python-django-discover-runner is an alternative Django "TEST_RUNNER" which
 uses the unittest2 test discovery from a base path specified in the settings,
 or any other module or package specified to the "test" management command,
 including app tests.


-- 
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/20130626065451.29226.27064.report...@buzig.gplhost.com