Bug#865353: libdvd-pkg: packages show up as obsolete packages, installs -dev and -dbgsym packaegs without need

[Christoph Anton Mitterer]

Package: libdvd-pkg
Version: 1.4.0-1-2
Severity: normal


Hi.

1) When running libdvd-pkg it installs all built packages automatically:
libdvdcss2
libdvdcss-dev
libdvdcss2-dbgsym
which is already not so nice.

2) These packages show up as local/obsolete packages, which isn't that nice 
either.
Can't you provide them in some simple local APT repo?
E.g. setting up a very basic repo-structure in /usr/src/libdvd-pkg (although 
this isn't probably
the proper place for this and rather some /var/cache/ location should be used).
and add that via a sources.list snipped in /etc/apt/sources.list.d/ ?

Then the admin could decide which pacakges to select from that repo.


I'd also suggest to regularly purge that basic repo, to get rid of old pacakges
there which may have security issues.

Cheers,
Chris.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#865349: libdvd-pkg doesn't necessarily really provide libdvdcss2/-dev

[Christoph Anton Mitterer]

Package: libdvd-pkg
Version: 1.4.0-1-2
Severity: normal


Hi.

libdvd-pkg provides the libdvdcss2 and libdvdcss-dev packages.

However, this is not really guaranteed, as installation may fail
or simply not be performed.

Thus it may be a bad idea to actually provide the packages, isn't it?

Cheers,
Chris.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#865348: libdvd-pkg: perhaps rename to libdvdcss-pkg?

[Christoph Anton Mitterer]

Package: libdvd-pkg
Version: 1.4.0-1-2
Severity: wishlist


Hi.

Well not so important, since it anyway provides libdvdcss2...
but wouldn't it make sense to name it libdvdcss-pkg?

Cheers,
Chris.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#865347: libdvd-pkg: use https for the download

[Christoph Anton Mitterer]

Package: libdvd-pkg
Version: 1.4.0-1-2
Severity: wishlist


Hi.

The videolan servers support https, I suggest using this for the download.
While this doesn't help with security, it adds privacy for the download process.

Of course one needs to add some --ca-certificate= to wget, of course best would
be to only add the CA that videoland actually uses, currently USERTrust RSA 
Certification Authority.
And one would need to depend on ca-certificates.


You should perhaps also update the watchfile.

btw: In get-orig-source, why do you use uscan to download the current version 
if downloading fails with wget?
That should then anyway not be usable due to the missing SHA256sum file,... and 
it won't be deleted then either, so
the user may accidentally use that unverified code.

Cheers,
Chris.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#835066: RFP: libhdcd -- HDCD (High Definition Compatible Digital) decoder

[Christoph Anton Mitterer]

Package: wnpp
Severity: wishlist

* Package name: libhdcd
  Version : git
  Upstream Author : Burt P. 
* URL : https://github.com/bp0/libhdcd
* License : BSD
  Programming Lang: C
  Description : HDCD (High Definition Compatible Digital) decoder


HDCD decoder code, originally in foo_hdcd, then
developed further as part of FFmpeg, then made
into this generic form.


CCing pkg-multimedia-maintainers@lists.alioth.debian.org, since this might
be also relevant for future FFmpeg versions :)

Cheers,
Chris.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

[Christoph Anton Mitterer]

Hey.

Andreas, anything new on this? What happened to your proposed patch?

Carl:
- The command lines are given in the initial mail of this bug.
- IIRC a sample link was provided somewhere as well, but if that
  doesn't suit you, simply take *any* wav file on earth, split it in
  two halfs a a position with sound, encode the resulting files with
  e.g. lame, process it with bs1770gain (and thus ffmpeg) and then
  you'll see how the gapless information gets destroyed.
- As for logs, this is always a bit tedious,... I did provide such logs
  in other bugs I've opened at ffmpeg upstream about gapless playback
  issues, with never any clear outcome.
  Since ffmpeg has quite some development pace, any such logs would be
  useless few weeks after I've posted them.
  If a developer actually looks into that issue, I can of course
  provide such logs, but since this is a general bug, it's really very
  easy to create sample files and logs oneself. I'd say it doesn't take
  5 mins, and for an audio developer probably even less.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#815692: mpv: new upstream version

[Christoph Anton Mitterer]

Package: mpv
Version: 0.14.0-1
Severity: wishlist


Hi.

AFAICS, there is a version 0.15 :-)

Cheers,
Chris.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

[Christoph Anton Mitterer]

On Sat, 2015-12-19 at 21:05 +0100, Andreas Cadhalpun wrote:
> Unless you can reproduce this with ffmpeg's test sample (in which
> case, please elaborate what the problem is), please send my privately
> (a link to) a small sample.
Wait a few minutes...

smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

[Christoph Anton Mitterer]

On Sat, 2015-12-19 at 20:59 +0100, Andreas Cadhalpun wrote:
> I might be missing what the problem is, but this command seems to
> work
> just fine with ffmpeg's test sample [1].
> Can you confirm this, or describe more precisely what the problem is?

You need two WAV files, which contain seamlessly playing sound (e.g.
just take any song and split it in the middle).

For lossless formats, there is typically no problem, that these two
play back again seamless (typically called "gapless").

When encoding them to lossy formats however, things get more tricky.
Different format provides for different means of gapless playback (or
none at all).
MP3 has e.g. two widespread ways, one by mean of LAME adding some
special tags, and itunes has something similar.
Opus/Vorbis/AAC, have similar things.

The problem was now, that when such gaplessly encoded files were
processed with bs1770gain, they were no longer gapless afterwards.

Peter thinks, due to a problem in the copy mode of ffmpeg.

If it's really that, and if you just do ffmpeg copy one one file, you
won't probably hear it... even when two audio files that belong
together, you may need to listen *very* closely to hear a gap.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

[Christoph Anton Mitterer]

On Sat, 2015-12-19 at 20:40 +0100, Petter Reinholdtsen wrote:
> As the bs1770gain developer Peter Belkner explain, this issue is
> really an issue in ffmpeg and not in bs1770gain.  Because of this, I
> reassign it to ffmpeg.
Well I think it's still also some kind of a design issue.

The problem is that ffmpeg, by nature a encoder/decoder, is always more
likely to actually change the different streams, than if the
application would just write to the respective meta-data/tags areas of
the file in question.

I also thought there would be quite a number of libs, which serve as a
more or less general purpose tagging lib.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

[Christoph Anton Mitterer]

On Sat, 2015-12-19 at 20:47 +0100, Andreas Cadhalpun wrote:
> Can you provide a sample for reproducing this problem?
Providing samples is always a bit problematic for copyrightreasons,
especially when providing them publicly.

Any CD-DA, which has gapless tracks (e.g. typically live CDs) will do.
If you don't have access to any, contact me off list.

Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

[Christoph Anton Mitterer]

On Sat, 2015-12-19 at 23:24 +0100, Andreas Cadhalpun wrote:
> OK, so the problem is that after remuxing with ffmpeg, there is
> a barely audible ... gap ... between the two files, right?
Yes

> Now I'm a bit skeptical about "LAME adding some special tags".
IIRC, the LAME tag isn't actually an ID3 tag, but padded in some other
parts of the MP3 header which aren't used.
http://gabriel.mp3-tech.org/mp3infotag.html
http://wiki.hydrogenaud.io/index.php?title=LAME#VBR_header_and_LAME_tag
http://libzplay.sourceforge.net/LAMETAG.html

> You've used lame with '--id3v2-utf16 --add-id3v2 --id3v1-only'.
> What is this supposed to do? Add id3v1 tags, or id3v2 or both?
IIRC the problem was that either bs1770gain but more likely python-
rgain (which I had to use in the end, because of the problem with
bs1770gain) didn't set any replay gain tags (which *are* in fact ID3
tags) at all, when no ID3 was present at all.

These options basically made, that both a ID3v1 and ID3v2 "section" was
created (the later with UTF16 encoding), however with no tags.


> Additionally it seems the created files contain neither.
Hmm... maybe I did in addition set one dummy tag like --tc=' ', and
removed that afterwards.


> And leaving out these id3 options doesn't change the output
> from lame.
> 
> So I'm not sure how this is supposed to work.
What exactly now? The stuff with the tags? I guess you can ignore that,
since I've just had it in place for, IIRC, python-rgain,...

What I would assume that ffmpeg does, is, that it simply drops or
somehow mangles up the LAMEtag,... or actually modifies the audio
stream so that it doesn't fit to the LAMEtag anymore.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#797963: bs1770gain: support writing Apple SoundCheck tags

[Christoph Anton Mitterer]

On Sat, 2015-12-19 at 23:38 +0100, Andreas Cadhalpun wrote:
> So is this a feature request to support iTunes Normalization Settings
> [1]?
If that's required for bs1770gain, then yes,... it's a feature request
:)

Apart from that, it may generally make sense for ffmpeg to support
these, i.e. when playing back files from proprietary-itunes-crap.

But it should perhaps default to take the replaygain tags when both are
present, since the later are more "mighty".

Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#805899: lame: suggest lame-doc

[Christoph Anton Mitterer]

Package: lame
Version: 3.99.5+repack1-9
Severity: wishlist


Hey.

Maybe it makes sense that lame suggests lame-doc :)

Cheers,
Chris.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#797965: BS1770GAIN

[Christoph Anton Mitterer]

Peter (=upstream) has asked me off list to check whether:
$ ffmpeg -i in.mp3 -acodec copy -y out.mp3
also makes the resulting files having gaps.
The back story is that bs1770gain apparently somehow uses ffmpeg.

And the answer is yes, after copying the files as above with ffmpeg,
they have gaps when played back.

So apart from the fact that I wonder why ffmpeg is used here at all
(shouldn't just some ID3 tags or that like be written?), it may be an
issue in ffmpeg.


btw: Using ffmpeg, even in copy mode seems to have other issues as
well:
ffmpeg version 2.7.2-2+b1 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 5.2.1 (Debian 5.2.1-15) 20150808
  configuration: --prefix=/usr --extra-version=2+b1 --build-suffix=-ffmpeg 
--toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu 
--incdir=/usr/include/x86_64-linux-gnu --enable-gpl --enable-shared 
--disable-stripping --enable-avresample --enable-avisynth --enable-frei0r 
--enable-gnutls --enable-ladspa --enable-libass --enable-libbluray 
--enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite 
--enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme 
--enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg 
--enable-openal --enable-libopus --enable-libpulse --enable-librtmp 
--enable-libschroedinger --enable-libshine --enable-libspeex --enable-libtheora 
--enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack 
--enable-libwebp --enable-libxvid --enable-libzvbi --enable-opengl 
--enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq 
--enable-libssh --enable-libx264 --enable-libopencv --enable-libx265
  WARNING: library configuration mismatch
  avcodec configuration: --prefix=/usr --extra-version=2+b1 
--build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu 
--incdir=/usr/include/x86_64-linux-gnu --enable-gpl --enable-shared 
--disable-stripping --enable-avresample --enable-avisynth --enable-frei0r 
--enable-gnutls --enable-ladspa --enable-libass --enable-libbluray 
--enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite 
--enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme 
--enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg 
--enable-openal --enable-libopus --enable-libpulse --enable-librtmp 
--enable-libschroedinger --enable-libshine --enable-libspeex --enable-libtheora 
--enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack 
--enable-libwebp --enable-libxvid --enable-libzvbi --enable-opengl 
--enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq 
--enable-libssh --enable-libx264 --enable-libopencv --enable-libx265 
--enable-version3 --disable-doc --disable-programs --disable-avdevice 
--disable-avfilter --disable-avformat --disable-avresample --disable-postproc 
--disable-swscale --enable-libopencore_amrnb --enable-libopencore_amrwb 
--enable-libvo_aacenc --enable-libvo_amrwbenc
  libavutil  54. 27.100 / 54. 27.100
  libavcodec 56. 41.100 / 56. 41.100
  libavformat56. 36.100 / 56. 36.100
  libavdevice56.  4.100 / 56.  4.100
  libavfilter 5. 16.101 /  5. 16.101
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale  3.  1.101 /  3.  1.101
  libswresample   1.  2.100 /  1.  2.100
  libpostproc53.  3.100 / 53.  3.100
[mp3 @ 0x15a8e40] Skipping 0 bytes of junk at 417.
Input #0, mp3, from '2.mp3':
  Duration: 00:10:45.09, start: 0.025057, bitrate: 166 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 166 kb/s
Metadata:
  encoder : LAME3.99r
Output #0, mp3, to 'b.mp3':
  Metadata:
TSSE: Lavf56.36.100
Stream #0:0: Audio: mp3, 44100 Hz, stereo, 166 kb/s
Metadata:
  encoder : LAME3.99r
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
[mp3 @ 0x15abba0] Audio packet of size 128 (starting with 54414700...) is 
invalid, writing it anyway.
size=   13141kB time=00:10:45.09 bitrate= 166.9kbits/s
video:0kB audio:13140kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: 0.003872%



As one can see above here, there's an error that ffmpeg thinks
something would be invalid.
It seems to still write it here, but I'd guess that the copy mode is
still like a full parsing and freshly rewriting.
Sounds like an invitation for all kinds of things going wrong :-(


@Peter: Why exactly do you need to use ffmpeg for writing? Shouldn't it
be enough to write some tags?


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#797838: faac: build with mp4v2

[Christoph Anton Mitterer]

One idea perhaps:

Could one fulfil the license if the lib was dynamically loaded?

I think about something what e.g. gtkpod does (which is, AFAICS als
gpl2 and still uses  libmp4v2)


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#797838: faac: build with mp4v2

[Christoph Anton Mitterer]

On Thu, 2015-09-03 at 07:11 +0200, Fabian Greffrath wrote:
> this is because libmp4v2 is licensed under the MPL-1.1 whereas faac
> is
> licensed under the GPL. Since both licenses are incompatible, the
> resulting binaries would be unredistributable.
Ah... I somehow missed that mp4v2 was MPL 1.1... thought it was 2.0

It's probably unreasonable trying to get a relicensing of it, isn't it?
:-(


Cheers,
Chris

smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

[Christoph Anton Mitterer]

Package: bs1770gain
Version: 0.4.5-1+b1
Severity: important
Tags: upstream


Hi.

It seems that bs1770gain somehow "destroys" gapless playback
on (at least) lame encoded MP3s.

For example, when I encode gapless WAV files via e.g.:
lame --verbose -q 0 -v -V 3 --noreplaygain --id3v2-utf16 --add-id3v2 
--id3v1-only 1.wav
lame --verbose -q 0 -v -V 3 --noreplaygain --id3v2-utf16 --add-id3v2 
--id3v1-only 2.wav
than the resulting 1.mp3 and 2.mp3 play flawlessly gapless
with e.g. mpv or on the ipod (mplayer or totem don't seem to
support gapless playback at all).

But once after I did e.g.:
$ bs1770gain -ismrpt --replaygain -o r/ music/
or:
$ bs1770gain -ismrpt  -o e/ music/
(with music containing the two MP3s) then the resulting MP3s in
e/ rspectively r/ no longer play gaplessly, neither with mpv
nor on the ipod.

When I do however:
$ collectiongain --regain music/
using the ReplayGain implementation from the python-rgain
package,
then the resulting files still play perfectly gapless
in mpv/ipod.


Cheers,
Chris.


PS: I've already notified upstream about this in a private
mail.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#797838: faac: build with mp4v2

[Christoph Anton Mitterer]

Package: faac
Version: 1.28+cvs20150510-1
Severity: wishlist


Hey.

libmp4v2 seems to be in debian main... is there any reason
why this has been disabled for faac? :-(

Cheers,
Chris.


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.1.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages faac depends on:
ii  libc6 2.19-19
ii  libfaac0  1.28+cvs20150510-1

faac recommends no packages.

faac suggests no packages.

-- no debconf information

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#795823: blender: Uninstallable in sid

[Christoph Anton Mitterer]

Control: reopen -1

Hey.

I doubt this won't be fixed by itself; as said in the bug mentioned by
the original reporter, boost 1.55 won't build with GCC5, so you'll have
to change the package to use a newer version (e.g. 1.58)... and I don't
think this would happen automatically by the transitions.


And even if, the issue would be still there so closing the bug isn't
justified =)


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#738554: libbluray-bdj security issues

[Christoph Anton Mitterer]

On Mon, 2015-05-04 at 07:42 +0200, Fabian Greffrath wrote: 
 It should be handled on the application level. The library's job is to
 parse and execute that stuff, not user interaction.
Well that's just the point.. I think this *is* a user decision.
Do you want to execute foreign code?

Nothing that the system could decide for the user.

It's - as I've said - similar to the Java Plugin case, where the user is
asked either.


 Maybe because it will be über-annoying to have to click away a debconf
 question each time you install e.g. vlc because you want to watch a
 DVD or listen to music or something else? Who will be really qualified
 to properly answer a question about such an implementation detail of the
 Bluray standard upon installation of a probably entirely unrelated
 package?
Not really a problem, is it? That question would be only asked once on
the first installation, and people could then either follow the default
choice or one could provide a simple explanation as well


 This will be about as helpful as the certificate exception click-away
 dialog in Firefox
Well but that dialogs are important... if you don't have them, TLS would
be even more useless than it already is.
And if a user is stupid and clicks it blindly away without
reading/understanding - his fault.
But not a reason that those have to suffer as well, who properly do
their homework.

 Alright, fine. But how about this for libc6?
 
 This library contains string manipulation functions that may read
 and/or write beyond array boundaries and are known to be exploitable.
 They may be called by foreign and even malicious code and even if they
 are run in a virtualization environment [...]
That's quite a difference... because for the later you still need to
first get some code locally where you do this.
If you install some software, which uses any C lib function
insecurely... well that's a security hole.

But here we just play a video, nothing where one would naturally assume
that foreign code get's executed.

As I've said,.. simply compare it with the Java Web Plugin example.
It's basically the same, conceptually.

Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#738554: libbluray-bdj security issues

[Christoph Anton Mitterer]

On Sun, 2015-05-03 at 09:16 +0200, Fabian Greffrath wrote: 
 If we had a bug opened against every package which *by principle* could
 hold a security issue, we'd have a lot.
Well as I've said... I guess one doesn't need to have much imagination
that one can think that a system like BD-J may be abused for attacks.

Any other similar things (where remote code, not distributed by Debian)
gets executed is considered a security risk and typically things move
away from having these enabled at all or at least not without further
asking the user.

Take Java web appelts as an example.

And there it's even usually well known that it's dangerous (while no one
may really notice what BD-J is) AND the Java plugin asks before actually
executing remote code (which is what I'd prefer for libbd-j as well).


 While I think a debconf prompt is absolutely of out of question, I'd
 agree that it may be useful to proactively warn users.
Well, the problem is, as you say, that the package description may not
be read at all...

I mean the best solution would probably be, that the library
(respectively the using program) asks before actually executing BD-J.

But since this is probably not going to happen soon,.. my next best idea
would have been a debconf notice.

And why should that be out of question?! Actually we have quite a number
of packages which fail to install when not answering something right
in debconf.
I don't see the problem.


 However, what warning added to the package description do you suggest?
Probably something like:
BD-J is a technology where foreign code provided by the BluRay medium is
executed on the local system.
This code may be even malicious and while it runs in a sandbox, one
should be familiar that there is no absolute guarantee that escaping
that sandbox is impossible.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#738554: libbluray-bdj security issues

[Christoph Anton Mitterer]

Control: reopen -1

Hey Sebastian.

On Sun, 2015-05-03 at 01:59 +0200, Sebastian Ramacher wrote: 
 libbluray now implements a Security Manager for BD-J code. From my point of
 view, the addition of the SM fixes this general complaint.
Phew.. I wouldn't think so.

That would be the first jailing technology where a break-out is
impossible.
Sandboxes where much more people work upon than it's probably the case
for libbluray-bdj are regularly hacked (e.g. Chromium, Firefox, etc.).
As I've said in the original report.


So I still think that the package description should include a warning
what this library actually does, i.e. executing code also specifically
meant for DRM, written by an industry which is known to intentionally
hack the systems of people, install rootkits for DRM related
surveillance, and so on.

Even better would be, if there was a critical debconf question which
informs the user, and which defaults to an answer the aborts installing
the package.


Even though I wouldn't know of a concrete security hole in this lib or
in the Security Manager you've mentioned, experience showed that such
things are a typical entry point for code execution.
So I think we should pro-actively warn users about this.

Therefore reopening the issue for now, until you decide that you don't
want to follow the idea with improved package description and/or the
debconf question.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#774800: libav: take measurements not to include or automatically download binary blobs

[Christoph Anton Mitterer]

On Wed, 2015-01-07 at 20:17 +0100, Sebastian Ramacher wrote: 
 Do you understand the change you've linked to?
As I've said, I've only had a first glance i.e. looking at the commit
log, which mentioned that the downloading must take place, but didn't
clearly say whether this is automated or not.

 I don't see a downloader anywhere.
Checking the current commit, I don't see one either (but OTOH that one
within firefox was also quite hidden)... but this isn't the point of
this bug, is it?
I didn't say remove an existing downloader, I've said take measurements
not to include or automatically download binary blobs,... i.e. by
adding a note to you internal maintainer TODO list or whatsoever.


 The user needs to download OpenH264 and rebuild libav to get
 OpenH264 support.
  So as long there is no package in Debian providing
 OpenH264, there won't be support for it in the libav package.
If it stays like this, then everything would be fine, but then I don't
quite understand why the commit log emphasizes the blob and why they
talk about a wrapper (or is this just because of the unstable ABI)? That
sounded quite like as if auto-downloading the blob for the user's
convenience was the planned way to go.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#774800: libav: take measurements not to include or automatically download binary blobs

[Christoph Anton Mitterer]

Source: libav
Severity: wishlist
Tags: security


Hi.

Apparently upstream has choosen the same stupid way, that Mozilla (see e.g. 
#769716)
did before to include OpenH264.

AFAICS on a first glance, this is done via downloading the blob distributed by
Cisco, for which no one knows what it really does - whether it's just a player
or NSA's most recent rootkit,... and in fact shortly after Mozilla started with 
that
infiltration a remotely exploitable hole was found in OpenH264 - shame be to 
him who
thinks evil of it.

Now allegedly these builds would be reproducible, but in reality that doesn't
seem to work (and I found so far no one who confirmed he was able to do so)... 
but
even if it would work, Debian would have to secure that for every new version,
i.e. reproduce the build, hard-code the hash of that build in the package and 
verify
it when the blob is downloaded.


So if libav actually goes that downloader way, then please disable this already 
in
advance (i.e. before the first systems are compromised with possible insecure 
blobs,
as it was the case with the iceweasel packages) and use the system library.


Cheers,
Chris.



[0] 
https://git.libav.org/?p=libav.git;a=commit;h=8a3d9ca603f4d15ecaa9ca379cbaab4ecaec8ce4utm_source=anzwix

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#774800: libav: take measurements not to include or automatically download binary blobs

[Christoph Anton Mitterer]

On Wed, 2015-01-07 at 20:07 +0100, Sebastian Ramacher wrote: 
 So, no bug here. There's not even an alpha release of libav 12 available
 yet.
Well... first, it was severity=wishlist, thus not necessarily a bug...
and 2nd, these changes will likely hit a release or may be introduced
via some snapshot release... and I think it's better to have a
notification that actions need to be taken then (downloading the blob
wouldn't just be a security compromise, but also a policy violation)...
in order not to fall into the same trap as iceweasel packages did.

Ignorantly closing this however, without any further discussion, doesn't
really shed a very bright light on security conscious decisions in the
maintenance process, does it?


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#741132: lives: opening a file makes the program crash

[Christoph Anton Mitterer]

Package: lives
Version: 2.2.2~ds0-1
Severity: grave
Justification: renders package unusable


Hi.

When opening a video file I get:
avformat detected format: mov,mp4,m4a,3gp,3g2,mj2
/usr/lib/lives/lives-exe: symbol lookup error: 
/usr/lib//lives/plugins/decoders/zzavformat_decoder.so: undefined symbol: 
av_find_stream_info

And the program crashes.


Cheers,
Chris.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lives depends on:
ii  frei0r-plugins1.1.22git20091109-1.4
ii  imagemagick   8:6.7.7.10+dfsg-1
ii  libasound21.0.27.2-3
ii  libatk1.0-0   2.10.0-2
ii  libavc1394-0  0.5.4-2
ii  libavcodec-extra-54   6:9.11-3
ii  libavformat54 6:9.11-3
ii  libavutil52   6:9.11-3
ii  libc6 2.18-4
ii  libcairo-gobject2 1.12.16-2
ii  libcairo2 1.12.16-2
ii  libdv41.0.0-6
ii  libfftw3-single3  3.3.3-7
ii  libgcc1   1:4.8.2-16
ii  libgdk-pixbuf2.0-02.30.5-1
ii  libgl1-mesa-glx [libgl1]  9.2.2-1
ii  libglee0d15.4.0-2
ii  libglib2.0-0  2.38.2-5
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libgtk-3-03.10.7-1
ii  libjack-jackd2-0 [libjack-0.116]  1.9.9.5+20130622git7de15e7a-1
ii  libmjpegutils-2.1-0   1:2.1.0+debian-2.1
ii  libogg0   1.3.1-1
ii  liboil0.3 0.3.17-2
ii  libpango-1.0-01.36.2-2
ii  libpangocairo-1.0-0   1.36.2-2
ii  libpng12-01.2.50-1
ii  libpulse0 4.0-6+b1
ii  libraw1394-11 2.1.0-1
ii  libsdl1.2debian   1.2.15-8
ii  libstdc++64.8.2-16
ii  libswscale2   6:9.11-3
ii  libtheora01.1.1+dfsg.1-3.1
ii  libunicap20.9.12-2
ii  libweed0  2.2.2~ds0-1
ii  libx11-6  2:1.6.2-1
ii  libxrender1   1:0.9.8-1
ii  lives-data2.2.2~ds0-1
ii  mplayer   2:1.0~rc4.dfsg1+svn34540-1+b2
ii  ogmtools  1:1.5-3+b1
ii  perl  5.18.2-2+b1
ii  procps1:3.3.9-4
ii  python2.7.5-5
ii  sox   14.4.1-3
ii  zlib1g1:1.2.8.dfsg-1

Versions of packages lives recommends:
pn  dvgrab none
pn  icedax none
ii  libtheora-bin  1.1.1+dfsg.1-3.1
ii  mencoder   2:1.0~rc4.dfsg1+svn34540-1+b2
ii  mkvtoolnix 6.8.0-1
ii  pulseaudio 4.0-6+b1
ii  x11-utils  7.7+1
pn  youtube-dl none

Versions of packages lives suggests:
pn  libdv-bin   none
ii  mjpegtools  1:2.1.0+debian-2.1

-- no debconf information

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#738554: libbluray-bdj security issues

[Christoph Anton Mitterer]

Package: libbluray-bdj
Version: 1:0.5.0-2
Severity: normal



Hi.

AFAIU, BD-J allows BluRays to run some Java code for an extended experience...

No even if that was sandboxed... we all know how problematic this is with 
respect
to security and that Java has a really bad record in terms of that.

In the end this probably means, that if installed, more or less arbitrary code
from BluRays (especially video BluRays) may be executed.


I think that at least the package description should clearly warn the user about
that, since many people may not fully realise what BD-J means.

And IMHO it would be even better, if libbluray-bdj was disabled by default,
even when installed... like that any function of it simply returns an error,
or that it's not loaded by libbluray unless some configuration file enables it
explicitly.


Cheers,
Chris.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#726838: mplayer depends upon old libavutil under unstable

[Christoph Anton Mitterer]

Removing mplayer in favour of mplayer2 seems to be quite a bad idea,...
as the later seems to be more or less dead upstream, while the former is
actively developed.

So this is probably a no-go.

It should be mentioned btw, that the mplayer and mplayer2 packages from
DMO just work fine (and can even be installed concurrently),... so I
wonder a bit why the ones from Debian can't.


Cheers,
Chris.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#726838: mplayer depends upon old libavutil under unstable

[Christoph Anton Mitterer]

severity 726838 grave
stop

Raising severity, since the issue makes the package uninstallable and
thus unusable.


Chris.


smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#719928: blender: stale files after upgrade

[Christoph Anton Mitterer]

reopen 719928
stop

Hey Matteo

Uhm...

On Wed, 2013-08-21 at 09:46 +0200, Matteo F. Vescovi wrote:
  On upgrade one gets these errors:
  Unpacking replacement blender ...
  dpkg: warning: unable to delete old directory 
  '/usr/lib/blender/scripts/presets/framerate': Directory not empty
  dpkg: warning: unable to delete old directory 
  '/usr/lib/blender/scripts/presets': Directory not empty

 The issue here is that those files are replaced by blender-data package
 now installing stuff under /usr/share and probably the installation
 process didn't know that.
Well it's not that easy...
1) dpkg provides means for files being moved from one package to the
other,... in which case these errors from above wouldn't appear.

2) Right now (I'm on sid) it doesn't seem the case as if blender-data
would contain any /usr/lib/blender stuff.

Actually no package seems to have files for that location registered
anymore... and it doesn't even exist anymore on my system.


So reopening for now :)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#719928: blender: stale files after upgrade

[Christoph Anton Mitterer]

Package: blender
Version: 2.68a-3
Severity: normal



Hi.

On upgrade one gets these errors:
Unpacking replacement blender ...
dpkg: warning: unable to delete old directory 
'/usr/lib/blender/scripts/presets/framerate': Directory not empty
dpkg: warning: unable to delete old directory 
'/usr/lib/blender/scripts/presets': Directory not empty

And stale files/dirs are left over:
$ l /usr/lib/blender/scripts/presets/framerate/__pycache__
total 21k
drwxr-xr-x 2 root root 4,1k Aug 17 00:14 .
drwxr-xr-x 3 root root 4,1k Aug 17 00:14 ..
-rw-r--r-- 1 root root  279 Aug  9 00:01 23.cpython-33.pyc
-rw-r--r-- 1 root root  279 Aug  9 00:01 29.cpython-33.pyc
-rw-r--r-- 1 root root  279 Aug  9 00:01 59.cpython-33.pyc

Cheers,
Chris.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.10-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages blender depends on:
ii  blender-data  2.68a-3
ii  fonts-droid   1:4.2.r1-2
ii  libavcodec54  9:1.2.2-dmo2
ii  libavdevice53 7:0.10.3-dmo1
ii  libavformat54 9:1.2.2-dmo2
ii  libavutil52   9:1.2.2-dmo2
ii  libboost-date-time1.49.0  1.49.0-4
ii  libboost-filesystem1.49.0 1.49.0-4
ii  libboost-locale1.49.0 1.49.0-4
ii  libboost-regex1.49.0  1.49.0-4
ii  libboost-system1.49.0 1.49.0-4
ii  libboost-thread1.49.0 1.49.0-4
ii  libc6 2.17-92
ii  libfftw3-double3  3.3.3-5
ii  libfreetype6  2.4.9-1.1
ii  libgcc1   1:4.8.1-9
ii  libgl1-mesa-glx [libgl1]  9.1.6-2
ii  libglew1.71.7.0-3
ii  libglu1-mesa [libglu1]9.0.0-1
ii  libgomp1  4.8.1-9
ii  libilmbase6   1.0.1-6
ii  libjack-jackd2-0 [libjack-0.116]  1.9.9.5+20130622git7de15e7a-1
ii  libjpeg8  8d-1
ii  libjs-jquery  1.7.2+dfsg-3
ii  libopenal11:1.14-4
ii  libopenexr6   1.6.1-7
ii  libopenimageio1.2 1.2.1~dfsg0-3
ii  libopenjpeg2  1.3+dfsg-4.6
ii  libpng12-01.2.49-4
ii  libpython3.3  3.3.2-5
ii  libsdl1.2debian   1.2.15-6
ii  libsndfile1   1.0.25-7
ii  libspnav0 0.2.2-1
ii  libstdc++64.8.1-9
ii  libswscale2   9:1.2.2-dmo2
ii  libtiff4  3.9.7-1
ii  libx11-6  2:1.6.1-1
ii  libxi62:1.7.2-1
ii  libxxf86vm1   1:1.1.3-1
ii  python3   3.3.2-13
ii  zlib1g1:1.2.8.dfsg-1

blender recommends no packages.

Versions of packages blender suggests:
pn  yafaray-exporter  none

-- no debconf information

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#578150: closable?

[Christoph Anton Mitterer]

Hi.

It seems 0.1.1 has been packaged?! Can we close this?


btw: Are you going to incorporate the upstream svn changes?
And are there any plans to package python-pycdio ?


Cheers,
Chris.



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers