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 that stuff, not user interaction. > 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. 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? This will be about as helpful as the "certificate exception" click-away dialog in Firefox and about as annoying as the click-through EULA dialogs in usual $otheros software. > 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. 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 [...]" Cheers, Fabian
signature.asc
Description: This is a digitally signed message part
