Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[IOhannes m zmölnig (Debian/GNU)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-07-29 03:20, Marco d'Itri wrote:
>> if they are not drop in replacements, and it would also be a
>> pain if
>>> higher up packages link-in both ffmpeg & libav and some 
>>> clashing symbols are present...
> This is why the new ffmpeg will use different symbols. Again, read 
> the first message.
> 

according to the first message, this is *not* true.
the packages will have different libraries-names / sonames, but this
does not mean that they don't have clashing symbols.
if both library foo (/usr/lib/libfoo.so.3.21) and library bar
(/usr/lib/i386-linux-gnu/libbar.so.4.1) export the symbol "knarzifax",
then how do you make sure that an application that is linked against
both libraries for different functionality always chooses the korrect
"knarzifax"?

this becomes a real world issue, as soon as plugins are involved
(which i find a common practice to access multimedia frameworks).
application "flurp" has a both "flurp-plugin-libav" and
"flurp-plugin-ffmpeg" installed.
whichever plugin is loaded first, will pull in a library that shadows
the symbol "knarzifax" for the *other* plugin.

fgamsdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJT10jZAAoJELZQGcR/ejb4o1AP/3aoHeFNZ3xcOLl/I0Y9g5Fp
GsejeqWuE59CTtoo/1jp5byhueA5Uw9LpmFOmfKttKvqG3sEXhIkXBOA9wATXYS1
uDsblHzuhKhKagmkQ42N1Ql0h+d7vkZA8/duaAtcSb+8HOU/peMRUMQx/MQyxF4X
z8hrmSHMpd9S2QTFJxjIfFa0kCQ9gtBv+p/2BSCRpLkxQBDyCoZeHwTmNQnpac4S
xYT5Qzo2YW7U5JKXjllHoKcvdBJ1+gYJYfByBcn7ZmHVSv2Ittu9pl7kgH+S1KPk
kdK9mopt3B0riCnIR+m3467TJ4U/F/UQ5VuZwENZ5GqivyiqvHHyyWnf3T2aa+rC
hZM+k7mF06kQzOWcRi9F9Mqa/Tt0myZKYZVqpJY/y4U6LUYeSAcNmr6b0vzUkxh1
9YG3RwXMLNQZz565Dw7NoqO/7BKgoviSwSnd6OpHruGIYfScPQGkh0q9eU8v4q0U
wazXWQ9ks1hHmp4Ea5QJuT+S/BQv3I5QEW0QYXn6flUkDeyj+T27djBisugive7g
yGWEr4sVGczzwXjo1T5vgYxNGzvxPeBWGUzJqsRtxqVZKYYyMLYdzNA0TUP1B3vK
rQQJXi7oXDTt/ta7yp09Pbp3ZHqxkJbjpLibgYoY9g9dIsEab25jahIK5xRBytz1
6BtDVvwo6srTgQEqOjzw
=vaCN
-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: https://lists.debian.org/53d748dc.4010...@debian.org

Re: apache2 issues

[Brian May]

On 29 Jul 2014 16:44, "Wouter Verhelst"  wrote:
> No, I don't.
>
> What brian really wants is apache2 or apache2-bin. In the case of
> apache2-bin, he needs an additional dependency on libapache2-mod-wsgi.
>
> Really, it should be
>
> apache2 | libapache2-mod-wsgi, apache2 | apache2-bin
>
> to do so.

Not sure I see how this is any better than just:

libapache2-mod-wsgi, apache2

(Which is what lintian warned me against using)

Installing libapache2-mod-wsgi and apache2-bin without apache2 is
insufficient, for Apache support to work, I need
/usr/share/apache2/apache2-maintscript-helper which requires apache2 to be
installed. So we can replace that 2nd term with just apache2.

Similarly, installing apache2 without libapache2-mod-wsgi would meet your
depends but not really be satisfactory.

Either way, it sounds like I should be ignoring Lintian.

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Raphael Geissert]

Andreas Cadhalpun wrote:
> According to the changelog[1], there have been 8 security updates for
> ffmpeg in squeeze. 

There would have been more but the code has evolved too much for it to be 
feasible to backport the patches. Not to mention that some bugs that are being 
fixed are, for example, for incomplete checks - checks that don't exist in the 
0.5 branch.



Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lr7jjb$np3$1...@ger.gmane.org

Re: apache2 issues

[Thorsten Glaser]

Brian May wrote:

>* "apache2-reverse-dependency-calls-invoke-rc.d" - due to legacy fall back
>code that restarts Apache2.2 automatically.

Yeah, I'm overriding this one too.

>* "non-standard-apache2-configuration-name" - due to the fact I need to
>supply different configuration files for apache2.2 and apache2.4 in
>/etc/apache2/conf-available, as the access control requirements have
>changed and this was the recommended solution on the debian-python mailing
>list.

Really?

No. Use  in one shared config file.
At least that's what I've been told, and what makes sense to me.

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lr7mp7$ngk$1...@ger.gmane.org

Re: apache2 issues

[Brian May]

On 29 July 2014 18:42, Thorsten Glaser  wrote:

> No. Use  in one shared config file.
> At least that's what I've been told, and what makes sense to me.
>

I wasn't aware of IfVersion. Thanks for the tip.
-- 
Brian May 

Bug#756363: ITP: sslsplit -- transparent and scalable SSL/TLS interception

[Hilko Bengen]

Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: sslsplit
  Version : 0.4.8
  Upstream Author : Daniel Roethlisberger 
* URL or Web page : http://www.roe.ch/SSLsplit
* License : BSD-2-clause
  Description : transparent and scalable SSL/TLS interception
SSLsplit is a tool for man-in-the-middle attacks against SSL/TLS
encrypted network connections. Connections are transparently
intercepted through a network address translation engine and
redirected to SSLsplit. SSLsplit terminates SSL/TLS and initiates a
new SSL/TLS connection to the original destination address, while
logging all data transmitted. SSLsplit is intended to be useful for
network forensics and penetration testing.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/874my0ilvu@msgid.hilluzination.de

Re: apache2 issues

[Jeroen Dekkers]

At Tue, 29 Jul 2014 17:29:46 +1000,
Brian May wrote:
> 
> On 29 Jul 2014 16:44, "Wouter Verhelst"  wrote:
> > No, I don't.
> >
> > What brian really wants is apache2 or apache2-bin. In the case of
> > apache2-bin, he needs an additional dependency on libapache2-mod-wsgi.
> >
> > Really, it should be
> >
> > apache2 | libapache2-mod-wsgi, apache2 | apache2-bin
> >
> > to do so.
> 
> Not sure I see how this is any better than just:
> 
> libapache2-mod-wsgi, apache2
> 
> (Which is what lintian warned me against using)
> 
> Installing libapache2-mod-wsgi and apache2-bin without apache2 is 
> insufficient, for Apache support to work, I need 
> /usr/share/apache2/apache2-maintscript-helper which requires apache2 to be 
> installed. So
> we can replace that 2nd term with just apache2.

As far as I can see this is a bug in the apache2 packaging. The httpd
virtual package should be provided by the apache2 package, not the
apache2-bin package, because the apache2-bin package doesn't provide a
working webserver. Bug report I just filed about this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756361
 
> Similarly, installing apache2 without libapache2-mod-wsgi would meet your 
> depends but not really be satisfactory.
> 
> Either way, it sounds like I should be ignoring Lintian.

No, lintian is correct and should not be ignored. Depending on only
apache2 makes it hard to run other webservers.

There is a also httpd-wsgi virtual package:
https://packages.debian.org/sid/httpd-wsgi 

A policy bug about what httpd-wsgi should provide is still open however:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588497

It isn't very easy to specify what httpd-wsgi should mean, because
some WSGI servers are full webservers with WSGI support such as apache
and others like gunicorn are only supposed to run behind a proxying
server such as apache or nginx (similar to for example php-fpm).

So as far as I can see, the correct dependency should be:

Depends: libapache2-mod-wsgi | httpd-wsgi, apache2 | httpd

So it also possible to run other webservers.


Kind regards,

Jeroen Dekkers


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/878unco7rv.wl%jer...@dekkers.ch

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Marco d'Itri]

On Jul 29, "\"IOhannes m zmölnig (Debian/GNU)\""  wrote:

> > This is why the new ffmpeg will use different symbols. Again, read 
> > the first message.
> according to the first message, this is *not* true.
It is:

- To avoid potential problems when a program is linked against
  FFmpeg libraries and other libraries, which in turn are linked
  against Libav, the symbol versions are changed to e.g.
  LIBAVCODEC_FFMPEG_55 instead of LIBAVCODEC_55.

https://lists.debian.org/debian-devel/2014/07/msg01010.html

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#756390: ITP: dune-grid-glue -- toolbox for solving PDEs -- compute couplings between grids

[Ansgar Burchardt]

Package: wnpp
Severity: wishlist
Owner: Ansgar Burchardt 

* Package name: dune-grid-glue
  Upstream Author : Christian Engwer ,
Oliver Sander 
* URL : http://www.dune-project.org/modules/dune-grid-glue/
* License : likely GPL-2 with an exception or LGPL
  Programming Lang: C++
  Description : toolbox for solving PDEs -- compute couplings between grids

dune-grid-glue provides infrastructure for the coupling of two
unrelated DUNE grids. The coupling may be overlapping or
nonoverlapping, conforming or nonconforming. The two grids are not
required to be of the same type, and they may even be of different
dimensions.

The package will be maintained in the Debian Science Team.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140729123701.6910.34550.report...@snout.igpm.rwth-aachen.de

Bug#756404: ITP: openpgp-applet -- GNOME applet for OpenPGP text encryption

[Clement Hermann]

(Couldn't add the correct pseudo-header to ask the BTS to CC'
debian-devel, so doing it now, with BTS notification attached)

Package: wnpp
Owner: "Clément Hermann (nodens)" 
Severity: wishlist

Package: wnpp
Severity: wishlist
Owner: "Clément Hermann (nodens)" 

* Package name: openpgp-applet
  Version : 0.8
  Upstream Author : Tails developers 
* URL :
https://tails.boum.org/doc/encryption_and_privacy/gpgapplet/
* License : (GPL/Artistic)
  Programming Lang: (Perl)
  Description : GNOME applet for OpenPGP text encryption

 OpenPGP_Applet allows encrypting and decrypting the content of the
 clipboard with a symmetric cipher using a passphrase. This is
 a graphical frontend on top of GnuPG.
 .
 Asymmetric decryption and clipboard verification are also supported.
 .
 Note : OpenPGP_Applet does not handle passphrase input. Since it also
does not
 offer terminal interaction unless explicitly run from there, it relies
 in practice on some kind of GnuPG agent such as pinentry, Seahorse 2.x
 or GNOME keyring 3.x to manage passphrase input.


OpenPGP_Applet is formerly part of Tails, the amnesic incognito live system,
and is now available as a standalone project for everyone to use :
 I'm packaging it upstream, and I'll be looking for a sponsor to
include it in debian (https://labs.riseup.net/code/issues/6507).

Cheers !

-- 
Clément Hermann (nodens)

--- Begin Message ---
Thank you for filing a new Bug report with Debian.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 w...@debian.org
 "Clément Hermann (nodens)" 

If you wish to submit further information on this problem, please
send it to 756...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
756404: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756404
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

--- End Message ---

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

Hi Dimitri,

On 29.07.2014 03:12, Dimitri John Ledkov wrote:

I don't have an opinion about ffmpeg vs libav, apart from how hard the
soname transitions are, especially in ubuntu where we somehow ended up
with ex-multimedia packages around that either never were in debian,
or have been long removed from testing and/or unstable.


There are only 6 additional reverse-build-dependencies of src:libav in 
utopic. Two build against lib*-ffmpeg-dev without further changes, one 
needs a simple patch to use pkg-config, one needs a patch to adapt to 
newer API (also needed for Libav 10), one is BD-uninstallable and one 
fails for unrelated reasons, but its build-dependencies on libav*-dev 
seem to be unnecessary anyway.


Per package list:

alsa-plugins-extra: OK
bombono-dvd: PATCH CodecID
dvdstyler: Unmet build dependencies: libwxsvg-dev (>= 2:1.0.9)
gstreamer-vaapi: error: unsupported GStreamer API version 1.4
kffmpegthumbnailer: OK
libdlna: PATCH pkg-config

The patches are attached to this mail.


Thankfully, we
have worked to make sure libav is in universe only and thus is not a
security maintenance burden. Nonetheless, libav10 transition is still
not complete in utopic today.


Is bombono-dvd the last blocker?


I haven't checked, but now abi
compatible/incompatible the two stacks are? cause it would be a pain
if they are not drop in replacements, and it would also be a pain if
higher up packages link-in both ffmpeg & libav and some clashing
symbols are present...


As Marco already wrote, FFmpeg is packaged to be ABI incompatible with 
Libav, having different sonames and different symbol versions.



and people start requesting to have build
variants against both.


This could theoretically be done, but I don't think anyone wants to 
maintain such a thing, especially because it would need two different 
source packages, as the development packages of FFmpeg and Libav have to 
conflict.



Has a rebuild of all deps been done? How many
build failures there are? (On both debian & ubuntu, ideally) Is
hardening flags / toolchain enabled in both, or either of the two?


I did a rebuild of all the reverse-build-dependencies in sid and the 
results can be found in my original mail.

For Ubuntu, see the beginning of this mail.

I'm not sure what you want to know about hardening.
The packages are otherwise unchanged, so use hardening flags if they 
already do.
If that question was about FFmpeg/Libav, then yes, FFmpeg uses 
--toolchain=hardened and Libav hardening flags.


Best regards,
Andreas
diff --git a/debian/patches/CodecID.patch b/debian/patches/CodecID.patch
new file mode 100644
index 000..e85d2da
--- /dev/null
+++ b/debian/patches/CodecID.patch
@@ -0,0 +1,51 @@
+Description: Rename CodecID to AVCodecID
+
+Author: Andreas Cadhalpun 
+Last-Update: <2014-07-29>
+
+--- bombono-dvd-1.2.2.orig/src/mgui/ffviewer.cpp
 bombono-dvd-1.2.2/src/mgui/ffviewer.cpp
+@@ -62,7 +62,7 @@ C_LINKAGE_BEGIN
+ 
+ typedef struct AVCodecTag {
+ #if LIBAVFORMAT_VERSION_INT >= AV_VERSION_INT(52,39,00)
+-enum CodecID id;
++enum AVCodecID id;
+ #else
+ int id;
+ #endif
+@@ -70,14 +70,14 @@ typedef struct AVCodecTag {
+ } AVCodecTag;
+ 
+ #if LIBAVFORMAT_VERSION_INT >= AV_VERSION_INT(52,34,00)
+-static uint FFCodecID2Tag(CodecID codec_id) 
++static uint FFCodecID2Tag(AVCodecID codec_id) 
+ {
+ unsigned int ff_codec_get_tag(const AVCodecTag *tags, int id);
+ extern const AVCodecTag ff_codec_bmp_tags[];
+ return ff_codec_get_tag(ff_codec_bmp_tags, codec_id);
+ }
+ #else
+-static uint FFCodecID2Tag(CodecID codec_id) 
++static uint FFCodecID2Tag(AVCodecID codec_id) 
+ {
+ unsigned int codec_get_tag(const AVCodecTag *tags, int id);
+ extern const AVCodecTag codec_bmp_tags[];
+@@ -388,7 +388,7 @@ static unsigned char GetChar(uint tag, i
+ return (tag>>bit_begin) & 0xFF;
+ }
+ 
+-static std::string CodecID2Str(CodecID codec_id)
++static std::string CodecID2Str(AVCodecID codec_id)
+ {
+ #ifdef _MSC_VER
+ std::string tag_str = boost::format("%1%") % codec_id % bf::stop;
+@@ -406,7 +406,7 @@ static std::string CodecID2Str(CodecID c
+ 
+ #else // CALC_FF_TAG
+ 
+-static std::string CodecID2Str(CodecID codec_id)
++static std::string CodecID2Str(AVCodecID codec_id)
+ {
+ return Int2Str(codec_id);
+ }
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..03ff5cf
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CodecID.patch
diff --git a/debian/control b/debian/control
index 4cd4492..a460e04 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Ubuntu MOTU Developers 
 Uploaders: Alexis Saettler 
 XSBC-Original-Maintainer: Alexis Saettler 
 Homepage: http://libdlna.geexbox.org
-Build-Depends: debhelper (>= 7.0.50), libavcodec-dev (>= 4:0.6), libavformat-dev (>= 4:0.7)
+Build-Depends: debhelper (>= 7.0.50), libavcodec-dev (>= 4:0.6), libavformat-dev (>= 4:0.7), pkg-config
 Standards-Version: 3.8.0
 
 Package: libdlna-dev
diff --git a/de

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

Hi Raphael,

On 29.07.2014 09:47, Raphael Geissert wrote:

Andreas Cadhalpun wrote:

According to the changelog[1], there have been 8 security updates for
ffmpeg in squeeze.


There would have been more


You're right, my calculation is slightly flawed.


but the code has evolved too much for it to be
feasible to backport the patches.


That is likely true for some, but not for others.

The real reason that there have not been more security updates for 
ffmpeg in squeeze is that since 0.5.6 this is actually Libav and Libav 
upstream stopped providing backports to 0.5 after 0.5.10 in February 
2013 [1]. FFmpeg upstream released 0.5.14 in July 2014 [2] with some 
more fixes [3].


So had both been in squeeze, there would have been four more, i.e. 16 
security updates.



Not to mention that some bugs that are being
fixed are, for example, for incomplete checks - checks that don't exist in the
0.5 branch.


What do you mean here? If the affected code is not there, then that's 
nice, because a backport is not needed.


Best regards,
Andreas

1: https://www.libav.org/releases/
2: https://www.ffmpeg.org/releases/
3: 
https://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=refs/heads/release/0.5



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d7cf25.3040...@googlemail.com

Bug#756430: ITP: bcmwl -- Broadcom 802.11 Linux STA wireless driver source

[Eduard Bloch]

Package: wnpp
Severity: wishlist
Owner: Eduard Bloch 

* Package name: bcmwl
  Version : 6.30.223.141+bdcom-0ubuntu3
  Upstream Author : Broadcom Corporation, http://www.broadcom.com
* URL : http://www.broadcom.com/support/802.11/linux_sta.php
* License : open source with precompiled objects (non-free)
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : Broadcom 802.11 Linux STA wireless driver source

These packages contain Broadcom's IEEE 802.11a/b/g/n hybrid Linux®
device driver for use with Broadcom's BCM4311-, BCM4312-, BCM4313-,
BCM4321-, BCM4322-, BCM43224-, and BCM43225-, BCM43227- and
BCM43228-based hardware.

Actually I plan to extend the existing Ubuntu package (bcmwl) a bit,
i.e. to include upstream changelog, add module-assistant as alternative
to dkms and fix a little bug preventing it's compilation with kernel
3.16-rc6.

Regards,
Eduard.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140729193302.ga21...@rotes76.wohnheim.uni-kl.de

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Pau Garcia i Quiles]

On Tue, Jul 29, 2014 at 6:10 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:


> I don't have an opinion about ffmpeg vs libav, apart from how hard the
>> soname transitions are, especially in ubuntu where we somehow ended up
>> with ex-multimedia packages around that either never were in debian,
>> or have been long removed from testing and/or unstable.
>>
>
> There are only 6 additional reverse-build-dependencies of src:libav in
> utopic. Two build against lib*-ffmpeg-dev without further changes, one
> needs a simple patch to use pkg-config, one needs a patch to adapt to newer
> API (also needed for Libav 10), one is BD-uninstallable and one fails for
> unrelated reasons, but its build-dependencies on libav*-dev seem to be
> unnecessary anyway.
>
> Per package list:
>
> alsa-plugins-extra: OK
> bombono-dvd: PATCH CodecID
> dvdstyler: Unmet build dependencies: libwxsvg-dev (>= 2:1.0.9)
> gstreamer-vaapi: error: unsupported GStreamer API version 1.4
> kffmpegthumbnailer: OK
> libdlna: PATCH pkg-config
>

In addition to this, I would like to note there is a lot of closed-source
software which uses ffmpeg instead of libav.

Not saying it doesn't exist but I don't know a single piece of
closed-source software which has moved from ffmpeg to libav.

I know, I know "non DFSG-free software, we don't care". Well, I do. E. g.
I'm having trouble with Qt right now because I'm using the commercial SDK
which indirectly uses ffmpeg to provide some codecs on Linux.

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

Re: Bug#756325: CVE-2014-5044: gfortran integer overflows

[Matthias Klose]

Control: tags -1 moreinfo
Control: severity -1 wishlist

Am 28.07.2014 um 22:10 schrieb Michael
Gilbert:python-pyasn1-modules_0.0.5-0ubuntu3_source.changes
> package: src:gcc-4.4, src:gcc-4.6, src:gcc-4.7, src:gcc-4.8, src:gcc-4.9
> severity: serious
> tags: security
> 
> Several integer overflow issues affecting all gcc versions have been
> fixed in libgfortran:
> http://www.openwall.com/lists/oss-security/2014/07/23/7
> 
> Best wishes,

maybe better wishful thinking? you should better stop filing "security" issues,
and better spend your time replying to the ones where more information is 
needed.

Florian Weimer is still listed as a member of the security team, although he
doesn't seem to do *anything* for Debian currently (apparently employed by Red
Hat).  So please catch up within the debian-security team first where you have
the better expertise, and pretty please don't bother anyone else before
addressing this within the security team.

thanks, and "best wishes", Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d7f935.3080...@debian.org

Re: Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Raphael Geissert]

On Tuesday 29 July 2014 18:43:17 Andreas Cadhalpun wrote:
> On 29.07.2014 09:47, Raphael Geissert wrote:
> > Andreas Cadhalpun wrote:
> >> According to the changelog[1], there have been 8 security updates for
> >> ffmpeg in squeeze.
> > 
> > There would have been more
> 
> You're right, my calculation is slightly flawed.

That was my point, so please don't use it as an argument.

> > Not to mention that some bugs that are being
> > fixed are, for example, for incomplete checks - checks that don't exist
> > in the 0.5 branch.
> 
> What do you mean here? If the affected code is not there, then that's
> nice, because a backport is not needed.

Let me rephrase it: the fix is for an incomplete check, but in 0.5 the check 
is missing - while the rest of the code is there. Which is kinda... worse.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/38022338.xExGetmtcr@eee

SSH upload queue stuck?

[Guillem Jover]

Hi!

As I'm not sure if this is being worked on, or even a known issue due
to the migration away from ravel, as I did't find any mention on the
BTS or RT, I'm just posting it here, so that others might also get
aware of any answer/status.

The SSH upload queue on
ssh.upload.debian.org:/srv/upload.debian.org/UploadQueue, in coccia.d.o
seems to be stuck, I'm guessing that either debianqueued (?) or a
cronjob or similar is missing, but I'm not sure if this needs DSA or
ftp-master intervention?

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140729201306.ga10...@gaara.hadrons.org

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

On 29.07.2014 21:59, Raphael Geissert wrote:

On Tuesday 29 July 2014 18:43:17 Andreas Cadhalpun wrote:

On 29.07.2014 09:47, Raphael Geissert wrote:

Andreas Cadhalpun wrote:

According to the changelog[1], there have been 8 security updates for
ffmpeg in squeeze.


There would have been more


You're right, my calculation is slightly flawed.


That was my point, so please don't use it as an argument.


Maybe I didn't make my point clear enough, for which the actual number 
of the security uploads is not important, only the order of magnitude.


Given the amount of software in Debian and thus the amount of security 
fixes necessary for a stable release, I think that the additional 
stable-security uploads for FFmpeg in the order of 10 per release will 
be hardly noticeable.


While I understand and agree with the general idea of reducing code 
duplication, I have a really hard time trying to understand why the 
security team has such a strong opposition to the idea of having both 
FFmpeg and Libav in Debian stable.


One argument against code duplication is the risk that security issues 
get fixed in one, but not in the other. But in this particular case 
FFmpeg upstream merges all security fixes from Libav, so an FFmpeg 
package in a stable release won't have that problem.


What is particularly hard for me to understand is why e.g. MySQL and 
MariaDB can be in testing at the same time without much resistance from 
the security team, but FFmpeg and Libav can apparently not.



Not to mention that some bugs that are being
fixed are, for example, for incomplete checks - checks that don't exist
in the 0.5 branch.


What do you mean here? If the affected code is not there, then that's
nice, because a backport is not needed.


Let me rephrase it: the fix is for an incomplete check, but in 0.5 the check
is missing - while the rest of the code is there. Which is kinda... worse.


Now I see, what you mean. Indeed that's worse, but if one notices 
something like that, then the whole check can be backported instead of 
the change in the check.
Though it probably would have been better to backport already the 
incomplete check, when it was introduced in the development branch.


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d80eda.8040...@googlemail.com

uploads to ssh.upload

[Joerg Jaspert]

Hi

whoever uploaded the following to ssh.upload.debian.org may want to do
so again (if you haven't already), as there was a bug in the config
after the move of ssh.upload.debian.org to coccia, deleting them...

spice-vdagent_0.15.0-1.1_amd64.changes
spice-vdagent_0.15.0-1.1_amd64.changes
udpkg_1.17_i386.changes
poppler_0.26.3-1~bpo70+1_amd64.changes
cups-filters_1.0.55-1_amd64.changes
cups_1.7.4-3_amd64.changes
epson-inkjet-printer-escpr_1.4.1-1_amd64.changes
txtorcon_0.10.1-1~bpo70+1_amd64.changes

Sorry for that.

-- 
bye, Joerg
AM: Whats the best way to find out if your debian/copyright is correct?
NM: Upload package into the NEW queue.


signature.asc
Description: PGP signature

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Russ Allbery]

Andreas Cadhalpun  writes:

> Given the amount of software in Debian and thus the amount of security
> fixes necessary for a stable release, I think that the additional
> stable-security uploads for FFmpeg in the order of 10 per release will
> be hardly noticeable.

Er, 8 security updates over the course of a stable release is already very
high.  Wouldn't adding another 10 make that the least secure source
package in Debian?  I believe that's worse than web browsers, which have a
very large attack surface and huge numbers of active and well-funded
attackers.  And this is just for a multimedia library.

I suppose it depends on how many of those could be grouped into one
update, and each Iceweasel update usually has multiple fixed CVEs, so
maybe this isn't an entirely fair comparison.  But still, those are
jaw-dropping numbers.

> While I understand and agree with the general idea of reducing code
> duplication, I have a really hard time trying to understand why the
> security team has such a strong opposition to the idea of having both
> FFmpeg and Libav in Debian stable.

Because the sorts of numbers that you're talking about indicate that this
code is a complete security disaster.

> What is particularly hard for me to understand is why e.g. MySQL and
> MariaDB can be in testing at the same time without much resistance from
> the security team, but FFmpeg and Libav can apparently not.

MySQL is already a security update problem due to Oracle's very unhelpful
attitude towards security patches.  And we're still talking about rather
fewer security vulnerabilities than this, I believe.

-- 
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: https://lists.debian.org/87ppgnhmym@windlord.stanford.edu

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

Hi Russ,

On 29.07.2014 23:30, Russ Allbery wrote:

Andreas Cadhalpun  writes:


Given the amount of software in Debian and thus the amount of security
fixes necessary for a stable release, I think that the additional
stable-security uploads for FFmpeg in the order of 10 per release will
be hardly noticeable.


Er, 8 security updates over the course of a stable release is already very
high.  Wouldn't adding another 10 make that the least secure source
package in Debian?  I believe that's worse than web browsers, which have a
very large attack surface and huge numbers of active and well-funded
attackers.  And this is just for a multimedia library.


I must have failed to make my point again. :(
As far as I know there are hundreds of security updates (for all 
packages together) in the lifetime of a stable release. Compared to that 
10 is not large. And, as I already mentioned, I think that some of the 
FFmpeg updates are minor enough to go through stable-updates.


It doesn't make a software less secure, if (even minor) security fixes 
get backported even to old release branches, rather the contrary.


Webbrowsers tend to have a lot more security issues and e.g. for Firefox 
15 security releases are planned in two years[2]. More importantly, 
Mozilla supports one release only for one year. That is much worse than 
the case of FFmpeg.
As e.g. the chromium browser uses FFmpeg[3] it is also under the 
scrutiny of the very same attackers and security researchers as webbrowsers.



I suppose it depends on how many of those could be grouped into one
update, and each Iceweasel update usually has multiple fixed CVEs, so
maybe this isn't an entirely fair comparison.  But still, those are
jaw-dropping numbers.


For the numbers of CVEs fixed in each FFmpeg release, please have a look 
at their security webpage[4]. Note how many of them get backported to 
old releases and if one isn't, that's probably because the old release 
didn't contain the vulnerable code.



While I understand and agree with the general idea of reducing code
duplication, I have a really hard time trying to understand why the
security team has such a strong opposition to the idea of having both
FFmpeg and Libav in Debian stable.


Because the sorts of numbers that you're talking about indicate that this
code is a complete security disaster.


Seen from a different point of view they show that the security support 
of FFmpeg is very good.



What is particularly hard for me to understand is why e.g. MySQL and
MariaDB can be in testing at the same time without much resistance from
the security team, but FFmpeg and Libav can apparently not.


MySQL is already a security update problem due to Oracle's very unhelpful
attitude towards security patches.  And we're still talking about rather
fewer security vulnerabilities than this, I believe.


So this gives me the impression that MySQL has a worse security support 
than FFmpeg, which doesn't really help to understand why the security 
team seems to be fine with having both forks of that in Debian testing.


Best regards,
Andreas


1: https://security-tracker.debian.org/tracker/source-package/libav
2: https://www.mozilla.org/en-US/firefox/organizations/faq/
3: 
https://src.chromium.org/svn/trunk/deps/third_party/ffmpeg/README.chromium

4: https://ffmpeg.org/security.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d82293.7010...@googlemail.com

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Russ Allbery]

Andreas Cadhalpun  writes:

> I must have failed to make my point again. :(
> As far as I know there are hundreds of security updates (for all packages
> together) in the lifetime of a stable release. Compared to that 10 is not
> large. And, as I already mentioned, I think that some of the FFmpeg
> updates are minor enough to go through stable-updates.

> It doesn't make a software less secure, if (even minor) security fixes get
> backported even to old release branches, rather the contrary.

Well... backporting security fixes more of a bare minimum -- that's just
something that has to happen if we're going to support the software at
all, with a handful of exceptions where the software is, for one reason or
another, important enough that we're willing to release with it even
though security patches aren't backported properly and then terminate
support in the middle of our normal stable process.

But software should also not pose a significant security load in the first
place.  That quantity of security vulnerabilities tells me that something
is deeply wrong with FFmpeg as an upstream source base.  That's a sign of
code with a bad smell.

Now, that doesn't necessarily mean that it doesn't belong in Debian.
Sometimes we have to hold our nose and live with that, and it sounds like
libav isn't necessarily a lot better.  But those are really painful
statistics that, to me at least, indicate the world is crying out for a
replacement code base that accomplishes the same goals but was written
with a higher level of quality in mind.

Obviously easier said than done, of course.

Is upstream aware that this is a really bad track record and trying to do
something proactive to increase the quality of the code, like
comprehensive auditing, or proactive rewrites to use more secure coding
practices such as some of the work that the LibreSSL team has been doing?

I'm sympathetic to the concerns of the security team and the release team
about supporting two code bases with this much security activity in a
stable release.  Maybe it's still the right thing to do, but that's a lot
of work for them.

-- 
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: https://lists.debian.org/87a97rhj3k@windlord.stanford.edu

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Russ Allbery]

Russ Allbery  writes:

> Is upstream aware that this is a really bad track record and trying to
> do something proactive to increase the quality of the code, like
> comprehensive auditing, or proactive rewrites to use more secure coding
> practices such as some of the work that the LibreSSL team has been
> doing?

Ah, I should have Googled my own question.

http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html

Well, that's... better than nothing.  It's certainly part of an overall
strategy, although that number of issues still indicates to me that there
are style and architecture issues here that could benefit from more
proactive design work.  I could be wrong, having not looked at the code
personally -- maybe the problem space is just really hard.  But that seems
like quite a lot of errors.

-- 
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: https://lists.debian.org/874mxzhirj@windlord.stanford.edu

Re: apache2 issues

[Brian May]

On 29 July 2014 09:40, Brian May  wrote:

>  if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
> . /usr/share/apache2/apache2-maintscript-helper
> apache2_invoke enconf package.conf
> elif  dpkg-query -f '${Version}'  -W 'apache2.2-common' > /dev/null 2>&1 ;
> then
> # if the configuration uses  uncomment the next line
> # a2enmod -q version
> [ -d /etc/apache2/conf.d/ ] && [ ! -l /etc/apache2/conf.d/package.conf
> ] && ln -s ../conf-available/package.conf /etc/apache2/conf.d/package.conf
> fi
>

Like I said, that 2nd condition doesn't seem to work correctly, and comes
with a false positive in sid if apache2-bin is installed (I still don't
understand this).

Maybe something like (full postinst file):

=== cut ===
#!/bin/sh -e

apache_force_reload() {

if apache2ctl configtest 2>/dev/null; then

invoke-rc.d apache2 restart || true

else

echo "Your apache2 configuration is broken, please fix it and
restart apache2 manually."
fi

}


if [ "$1" = "configure" ]; then
if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
. /usr/share/apache2/apache2-maintscript-helper
apache2_invoke enconf package.conf
elif  command -v apache2 > /dev/null && apache2 -v | sed -n 's/^Server
version: //p' | grep -q 'Apache/2.2'; then
ln -sf ../conf-available/package.conf
/etc/apache2/conf.d/package.conf
apache_force_reload
fi
fi

#DEBHELPER#
=== cut ===

It appears to work both on wheezy and sid.

The ln -sf might be an oversimplification, will fail if the sysadmin has
deleted /etc/apache2/conf.d - I consider this unlikely however.

Possibly #DEBHELPER# should come first.

It also appears that "a2enmod -q version" is not required, and generates an
error, both on wheezy and sid, so I removed that comment.
-- 
Brian May 

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

On 30.07.2014 00:54, Russ Allbery wrote:

Andreas Cadhalpun  writes:


I must have failed to make my point again. :(
As far as I know there are hundreds of security updates (for all packages
together) in the lifetime of a stable release. Compared to that 10 is not
large. And, as I already mentioned, I think that some of the FFmpeg
updates are minor enough to go through stable-updates.



It doesn't make a software less secure, if (even minor) security fixes get
backported even to old release branches, rather the contrary.


Well... backporting security fixes more of a bare minimum -- that's just
something that has to happen if we're going to support the software at
all, with a handful of exceptions where the software is, for one reason or
another, important enough that we're willing to release with it even
though security patches aren't backported properly and then terminate
support in the middle of our normal stable process.


So it's good that FFmpeg upstream does that backporting.


But software should also not pose a significant security load in the first
place.  That quantity of security vulnerabilities tells me that something
is deeply wrong with FFmpeg as an upstream source base.  That's a sign of
code with a bad smell.


In my opinion the large amount of security fixes is due to the fact that 
FFmpeg is a large codebase and that most of the code has to deal with 
untrusted data, a.k.a. multimedia files.



Now, that doesn't necessarily mean that it doesn't belong in Debian.
Sometimes we have to hold our nose and live with that, and it sounds like
libav isn't necessarily a lot better.


On the contrary I think that Libav is worse, as it doesn't even apply 
all patches for security vulnerabilities fixed in FFmpeg that also 
affect Libav. Just have a look at the security tracker of Libav[1].



 But those are really painful
statistics that, to me at least, indicate the world is crying out for a
replacement code base that accomplishes the same goals but was written
with a higher level of quality in mind.

Obviously easier said than done, of course.


The time needed to do that would likely be spent a lot better with 
trying to find and fix the remaining vulnerabilities in FFmpeg, because 
any rewrite of such a large code base inevitably introduces it's own 
security bugs.



Is upstream aware that this is a really bad track record and trying to do
something proactive to increase the quality of the code, like
comprehensive auditing, or proactive rewrites to use more secure coding
practices such as some of the work that the LibreSSL team has been doing?


On 30.07.2014 01:01, Russ Allbery wrote:
> Ah, I should have Googled my own question.
>
> 
http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html

>
> Well, that's... better than nothing.  It's certainly part of an
> overall strategy, although that number of issues still indicates to
> me that there are style and architecture issues here that could
> benefit from more proactive design work.  I could be wrong, having
> not looked at the code personally -- maybe the problem space is just
> really hard.  But that seems like quite a lot of errors.

You could also have asked FFmpeg upstream. (I've CCed Michael 
Niedermayer now.)



I'm sympathetic to the concerns of the security team and the release team
about supporting two code bases with this much security activity in a
stable release.  Maybe it's still the right thing to do, but that's a lot
of work for them.


Of course I'm also sympathetic with the concerns of the security and 
release teams. But given that the alternatives are either to drop Libav, 
which the Libav maintainers would probably be unhappy about, or not 
having FFmpeg in the next stable release, which a lot of other people 
would be unhappy about, having both in stable seems like the least bad 
solution.


Best regards,
Andreas

1: https://security-tracker.debian.org/tracker/source-package/libav


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d83869.90...@googlemail.com

Re: apache2 issues

[Brian May]

On 29 July 2014 19:04, Jeroen Dekkers  wrote:

> As far as I can see this is a bug in the apache2 packaging. The httpd
> virtual package should be provided by the apache2 package, not the
> apache2-bin package, because the apache2-bin package doesn't provide a
> working webserver. Bug report I just filed about this:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756361


[...]


> A policy bug about what httpd-wsgi should provide is still open however:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588497
>
> It isn't very easy to specify what httpd-wsgi should mean, because
> some WSGI servers are full webservers with WSGI support such as apache
> and others like gunicorn are only supposed to run behind a proxying
> server such as apache or nginx (similar to for example php-fpm).
>

Thanks for the BTS references. Looks like I should keep using
"libapache2-mod-wsgi, apache2" for now, but be prepared to change this
depending on what happens with #756361.


So as far as I can see, the correct dependency should be:
>
> Depends: libapache2-mod-wsgi | httpd-wsgi, apache2 | httpd
>
> So it also possible to run other webservers.
>

Yes, that looks good to me. Suspect the actual line may depend on what
happens with #588497.
-- 
Brian May 

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Michael Niedermayer]

On Wed, Jul 30, 2014 at 02:12:25AM +0200, Andreas Cadhalpun wrote:
> On 30.07.2014 00:54, Russ Allbery wrote:
> >Andreas Cadhalpun  writes:
> >
> >>I must have failed to make my point again. :(
> >>As far as I know there are hundreds of security updates (for all packages
> >>together) in the lifetime of a stable release. Compared to that 10 is not
> >>large. And, as I already mentioned, I think that some of the FFmpeg
> >>updates are minor enough to go through stable-updates.
> >
> >>It doesn't make a software less secure, if (even minor) security fixes get
> >>backported even to old release branches, rather the contrary.
> >
> >Well... backporting security fixes more of a bare minimum -- that's just
> >something that has to happen if we're going to support the software at
> >all, with a handful of exceptions where the software is, for one reason or
> >another, important enough that we're willing to release with it even
> >though security patches aren't backported properly and then terminate
> >support in the middle of our normal stable process.
> 
> So it's good that FFmpeg upstream does that backporting.
> 
> >But software should also not pose a significant security load in the first
> >place.  That quantity of security vulnerabilities tells me that something
> >is deeply wrong with FFmpeg as an upstream source base.  That's a sign of
> >code with a bad smell.
> 
> In my opinion the large amount of security fixes is due to the fact
> that FFmpeg is a large codebase and that most of the code has to
> deal with untrusted data, a.k.a. multimedia files.
> 
> >Now, that doesn't necessarily mean that it doesn't belong in Debian.
> >Sometimes we have to hold our nose and live with that, and it sounds like
> >libav isn't necessarily a lot better.
> 
> On the contrary I think that Libav is worse, as it doesn't even
> apply all patches for security vulnerabilities fixed in FFmpeg that
> also affect Libav. Just have a look at the security tracker of
> Libav[1].
> 
> > But those are really painful
> >statistics that, to me at least, indicate the world is crying out for a
> >replacement code base that accomplishes the same goals but was written
> >with a higher level of quality in mind.
> >
> >Obviously easier said than done, of course.
> 
> The time needed to do that would likely be spent a lot better with
> trying to find and fix the remaining vulnerabilities in FFmpeg,
> because any rewrite of such a large code base inevitably introduces
> it's own security bugs.
> 
> >Is upstream aware that this is a really bad track record and trying to do
> >something proactive to increase the quality of the code, like
> >comprehensive auditing, or proactive rewrites to use more secure coding
> >practices such as some of the work that the LibreSSL team has been doing?
> 
> On 30.07.2014 01:01, Russ Allbery wrote:
> > Ah, I should have Googled my own question.
> >
> > http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html
> >
> > Well, that's... better than nothing.  It's certainly part of an
> > overall strategy, although that number of issues still indicates to
> > me that there are style and architecture issues here that could
> > benefit from more proactive design work.  I could be wrong, having
> > not looked at the code personally -- maybe the problem space is just
> > really hard.  But that seems like quite a lot of errors.
> 
> You could also have asked FFmpeg upstream. (I've CCed Michael
> Niedermayer now.)

Yes the problem space is hard ...
The problem with multimedia in relation to security is that
* There are hundreads of different formats, requireing alot of code
   to support them
* The input files and streams can generally not be trusted, which
   makes most of the code security relevant and a potential target for
   an exploit
* Many and especially the most important and efficient formats are
   very complex
* The code must be very fast, users want to see their movies play
   in realtime not waiting for each frame to be decoded. And most of
   the code is speed relevant

Above applies to any implementation, and constrains architecture
options ...

What we do to combat that is
All patches going into FFmpeg are reviewed with security in mind

The codebase was repeatledly tested with fuzzed files to uncover
all kinds of anomalies, all such found anomalies where fixed.
Also independant of googles fuzzing efforts, some of our users
have done their own fuzzing. And during google code in several
students have as well manually tried to find security issues.

FFmpeg is regularly tested with static code analyzsers like coverity
and most issues found get quickly fixed

FFmpeg is tested regularly with runtime memory checkers like
valgrind, address sanitizer and others and all reproduceable issues
are fixed, iam not aware of any open and reproduceable one

Almost all of the internal APIs used in FFmpeg are designed to be
secure, always passing array sizes and checking them instead of
assuming the call

Bug#745135: RFS: mariadb-10.0/10.0.10-1 [ITP] -- Latest version of worlds most popular non-Oracle database

[Arnaud Fontaine]

Hello,

Any reason why MariaDB 10.0.10 (uploaded to experimental) is still
stucked in the NEW queue? I would really like to see this version of
MariaDB in the next stable release so let me know if any help is
needed. Thanks for all your work!

Cheers,
-- 
Arnaud Fontaine


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a97rberq@duckcorp.org

Re: apache2 issues

[Jonas Smedegaard]

Quoting Brian May (2014-07-30 02:54:10)
> On 29 July 2014 19:04, Jeroen Dekkers <[1]jer...@dekkers.ch> wrote:
> 
>  As far as I can see this is a bug in the apache2 packaging. The httpd
>  virtual package should be provided by the apache2 package, not the
>  apache2-bin package, because the apache2-bin package doesn't provide a
>  working webserver. Bug report I just filed about this:
>  [2]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756361
> 
> 
>[...]
> 
> 
>  A policy bug about what httpd-wsgi should provide is still open however:
>  [3]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588497
> 
>  It isn't very easy to specify what httpd-wsgi should mean, because
>  some WSGI servers are full webservers with WSGI support such as apache
>  and others like gunicorn are only supposed to run behind a proxying
>  server such as apache or nginx (similar to for example php-fpm).
> 
>Thanks for the BTS references. Looks like I should keep using
>"libapache2-mod-wsgi, apache2" for now, but be prepared to change this
>depending on what happens with #756361.
> 
> 
>  So as far as I can see, the correct dependency should be:
> 
>  Depends: libapache2-mod-wsgi | httpd-wsgi, apache2 | httpd
> 
>  So it also possible to run other webservers.
> 
>Yes, that looks good to me. Suspect the actual line may depend on what
>happens with #588497.

You might then want to formally second that phrasing, then - i.e. 
sharing your opinion at the bugreport (I just did so myself), thanks to 
your raising awareness :-) .

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Joseph Neal]

What we do to combat that is  All patches going into FFmpeg are

> reviewed with security in mind
>
> The codebase was repeatledly tested with fuzzed files to uncover all
> kinds of anomalies, all such found anomalies where fixed. Also
> independant of googles fuzzing efforts, some of our users have done
> their own fuzzing. And during google code in several students have as
> well manually tried to find security issues.
>
> FFmpeg is regularly tested with static code analyzsers like coverity
> and most issues found get quickly fixed
>
> FFmpeg is tested regularly with runtime memory checkers like
> valgrind, address sanitizer and others and all reproduceable issues
> are fixed, iam not aware of any open and reproduceable one
>
> Almost all of the internal APIs used in FFmpeg are designed to be
> secure, always passing array sizes and checking them instead of
> assuming the caller knows they are large enough, exceptions to this
> are just the most speed critical parts.
>
> Codecs which are WIP and arent up to security standards can be and
> are marked as experimental and will not be selected during
> autodetection unless overriden by the user.

Something else to add to this list is that ffmpeg has a far larger base 
of installed users bring the "more eyes" principle into play. I can't 
speak as to how many linux distros use which fork, though I believe the 
vast majority of all libav installs are debian and its derivatives.  
Ffmpeg, meanwhile, has a huge install base in the Windows and to a 
lessor degree Macintosh worlds as the backend to nearly every free video 
player or transcoder out there.   Virtually no upstreams with a choice 
are adopting libav, and I expect the number of those supporting it to 
dwindle as it continues drift away from ffmeg.


I don't see this as being much different from the 
imagemagik/graphicsmagic situation.


Sorry if my message formatting is screwed up.  I'm on windows and have 
no idea what I'm doing.