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
Am Sonntag, den 03.05.2015, 02:12 +0200 schrieb Christoph Anton
Mitterer:
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.).
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
Am Sonntag, den 03.05.2015, 09:33 +0200 schrieb Christoph Anton
Mitterer:
I mean the best solution would probably be, that the library
(respectively the using program) asks before actually executing BD-J.
It should be handled on the application level. The library's job is to
parse and execute
Processing control commands:
reopen -1
Bug #738554 {Done: Sebastian Ramacher sramac...@debian.org} [libbluray-bdj]
libbluray-bdj security issues
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug
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
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.
