Re: flashplugin-nonfree get-upstream-version.pl security concern
On Wed, Dec 12, 2012 at 11:41 PM, Jason Fergus wrote:
> On Wed, 2012-12-12 at 17:26 -0500, Michael Gilbert wrote:
>> On Wed, Dec 12, 2012 at 12:52 PM, adrelanos wrote:
>> > What is Debian policy on code execution from user websites?
>>
>> Unfortunately there is none. I've tried to gain consensus that at a
>> minimum things downloaders like this need to stay out of main, but
>> that thought hasn't really gained traction.
>>
>> The real answer is that this package is in contrib and thus not
>> security supported at all. Ultimately, for anyone even modestly
>> security-conscious adobe flash should really be avoided at all costs.
>> Alternatives include lightspark, gnash, and (most preferably) html5.
>>
>> Best wishes,
>> Mike
>>
>>
> I could be wrong on this, but I had always thought that ANY sort of
> downloader type installer (like the flashplugin-nonfree package) could
> NOT be in main. For any package to be in main, it has to have source
> code available as well as DFSG compliant. It's the same reason why
> quake2-data packages were always in contrib. While the source code for
> quake2 is GPL, the -data package would grab the pk0.pak files off of the
> CD to put them in the proper place for global Quake 2 fun. quake2-data
> was always in contrib. I was going to use qmail as an example, but I am
> guessing they changed their license recently, because previous to
> Wheezy, you always had to build it from source (and there was a
> qmail-src package).
You would think that, but Debian policy has nothing to say. I put a
lot of energy into it, but things like getweb still remain:
http://bugs.debian.org/449497
These cases are actually pretty rare, which is the real reason that
there is no defined policy. Plus people tend to not like repacking
upstream due to single questionable files.
> Anyhow, I hope that point was made clear. Contrib also does get
> security updates, but they're not maintained by the security team (if
> I'm recalling correctly. Sucks getting old). They're simply maintained
> by the package maintainer.
Well, there's always the option for the maintainer to provide a
security update an spu, but that is so rare in contrib that I don't
recall the last time it happened.
Without security team intervention happens in probably 95% of cases
for security issues, so there's something like a 5% of a fix going
into contrib. Maintainers tend to lose interest in the stable release
fairly quickly.
Best wishes,
Mike
Reply to: