Re: Pepper Flash plugin installer package

[Bart Martens <bartm@debian.org>]

On Sat, Feb 02, 2013 at 01:01:13AM -0500, Daniel Richard G. wrote:
> On Fri, 2013 Feb  1 23:17+0000, Bart Martens wrote:
> >
> > In Debian flashplugin-nonfree uses checksums that I update separate
> > from the flashplugin-nonfree package, so that the flashplugin-
> > nonfree package itself doesn't need to be updated for every new Adobe
> > Flash Player.
> 
> That avoids the problem with delayed binary builds,

Yes.

> but how do clients get security updates automatically, a la
> unattended-upgrades?  I see that running update-flashplugin-nonfree will
> download the latest plugin, but there is no option/mechanism to run that
> regularly.

I agree that it doesn't solve that.

I see two types of security updates for flashplugin-nonfree :

The first type of security updates are for the Adobe Flash Player itself.
These updates by Adobe are (were?) often combined with new features.  I
understand Debian's rather conservative approach that such updates are not
suitable for injection into stable via security.debian.org.  On the other hand,
I expect most users to want to install all Adobe's security fixes without delay
even with new features, so I think users' expectation and Debian's conservative
approach on this are not exactly matching.  At this point the user of
flashplugin-nonfree should follow security related information on Adobe's
website, and run update-flashplugin-nonfree when he/she wants to install the
newer Adobe Flash Player.  It's the best support I could think of, within
Debian's policies.

The second type of security updates are for fixing security bugs in the
flashplugin-nonfree package itself.  Fortunately these don't happen so ofteh,
but we had such security bug recently.  I prepared an update for
security.debian.org (section contrib), but the Debian Security Team refused to
distribute it via security.debian.org because they were too busy with section
main already.  I don't understand this, because it was just a matter of a
permission to release the package via the existing infrastructure.  So I
offered to join the Debian Security Team for section contrib, but then I got no
reply anymore.  I got the security fix distributed via a stable point release,
meaning that many users got the fix much later.  I think we (=Debian) can do
better than this.

> Anyway, Ubuntu's package, and the one I put together, rely on update-
> notifier to do the download, which requires a known URL and SHA-256.
> Does your package handle failed downloads gracefully? As I understand,
> that's why the Ubuntu folks switched to using update-notifier:
> 
>     https://wiki.ubuntu.com/Specs/UpdateNotifierPackageDataDownloader

Interesting approach.  Of course this only works for users using
update-notifier, not for users doing package updates via apt-get, but still an
interesting approach, since users of flashplugin-nonfree are usually desktop
users using update-notifier.  I don't think the design is ready to be combined
with the current design of flashplugin-nonfree with separately maintained
checksums, but it's a good idea worth exploring.

> > Maybe Canonical has a special agreement with Adobe, no idea.  In
> > Debian I prefer to not rely on a special agreement.
> 
> I understand why special agreements are anathema for Debian, but my
> point is that a quick reading of the EULA suggests that third parties in
> general might be permitted to distribute Pepper Flash. (I don't think
> Canonical has a special agreement with Adobe, even, but I'm not assuming
> the terms for PPAPI Flash are the same as for NPAPI Flash.) Have a look
> at section "Google Chrome Additional Terms of Service," subsection
> "Adobe," clauses 2 "Electronic Transmission" and 3 "EULA and
> Distribution Terms":
> 
>     https://www.google.com/chrome/intl/en/eula_text.html
> 
> Do you think it may be worth bringing this up on debian-legal?

If you want that, go ahead.

> Being able to download the Pepper Flash files from a different location would
> make an installer package much easier to put together.

You would get control over the download site, but any installer package would
still need to deal with failed downloads, so the improvement would be limited.

> Who knows---it
> might even be possible to distribute the plugin files directly in a non-
> free package, so we don't have to worry about downloading them at all.

That would be a huge improvement.  Still, new Adobe Flash Player versions with
security fixes and new features combined would still need to go via backports,
not via security.debian.org because we can't separate the security fixes.

> > > I don't have a good place to host it, and even then I probably
> > > couldn't afford the bandwidth.
> >
> > Are you asking to support the distribution of pepper flash in Debian ?
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679866
> 
> I'd be happy to put together a new package for Pepper Flash, but I would
> want a third-party download site for the upstream files (like
> Canonical's), or some other solution that avoids 404s whenever Google
> puts out a new release.

I'm sure you can find hosting without charge somewhere for this.  If you want
to go ahead with this, make sure you submit an "intent to package" (ITP), and
be prepared to defend your plans on debian-devel.

> One idea: Is it possible to check the signature on a .deb file in a way
> that is simple enough to put in a package script? Because then I could
> just rely on Google's unversioned download URL, which always works:
> 
>     https://dl.google.com/linux/direct/google-chrome-stable_current_{amd64,i386}.deb
> 
> I've looked at debsig-verify and dpkg-sig, and couldn't figure out
> either one.

Do these .deb files have signatures ? I don't think so.

Regards,

Bart Martens