snaps must have accompanying source available

Bug #1711333 reported by Jonathan Riddell
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Snapcraft
Triaged
Wishlist
Unassigned

Bug Description

snap packages include open source software. To ensure compliance with licencing and ensure the continued development of this open source users of snaps must be able to download the source code used to create a snap.

Developers must be able (probably required) to upload sources and maybe pointers to .debs used which will persist for the lifetime of the snap.

Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 1711333] [NEW] snaps must have accompanying source available

Yes, this is an agreed goal, together with things like debug artifacts
(symbols). It is also important so that we can automate the process of
notifying publishers about security issues in dependency libraries that
would warrant a rebuild.

Revision history for this message
Oliver Grawert (ogra) wrote :

snaps nowadays ship /snap/<snap name>/current/snap/snapcraft.yaml which should have most/all build information in it already ... (upstream source, binaries that are used from the archive, patches (or at least a source to the build system used to build it to look up patches))

That said ... if you use a set of prebuilt proprietary binaries you just copy in place using the dump plugin you can indeed work around everything (but i think we do not want to limit packagers or force them to opensource-only software...)

Revision history for this message
Adam Conrad (adconrad) wrote : Re: [Bug 1711333] Re: snaps must have accompanying source available

On Fri, Aug 18, 2017 at 09:58:25AM -0000, Oliver Grawert wrote:
> snaps nowadays ship /snap/<snap name>/current/snap/snapcraft.yaml which
> should have most/all build information in it already ... (upstream
> source, binaries that are used from the archive, patches (or at least a
> source to the build system used to build it to look up patches))

Saying "we're pretty sure the source is over there somewhere" does not
satisfy our responsibility when distributing GPL binaries. We need to
be able to respond to requests for the source EVEN IF the upstream has
deleted the branches, etc. Which means we need a copy of it.

And, if we take a copy of it, then we can avoid the whole bit where we
have to respond to requests for the source by just making the source
available discoverably next to the binaries, like we do in Debian/APT
style archives.

This isn't a "nice-to-have", it's a legal obligation if we distribute
binaries licensed under the GPL, which we're doing.

... Adam

Revision history for this message
Oliver Grawert (ogra) wrote :

"Saying "we're pretty sure the source is over there somewhere" does not
satisfy our responsibility when distributing GPL binaries."

well, the snapcraft.yaml is the *exact* build reciepe ... but yeah, that doesnt protect from the packager deleting the original branch after publishing ...

Revision history for this message
Sergio Schvezov (sergiusens) wrote :

We are working on recording all assets of a snap, including additional assets brought in like plugins. We can certainly work on some tooling to read this recording and generate a snapshot of assets.

Changed in snapcraft:
importance: Undecided → Wishlist
status: New → Triaged
Revision history for this message
Casey (casey-jao) wrote :

>well, the snapcraft.yaml is the *exact* build reciepe

The snapcraft.yaml does not necessarily record all the information needed to reproduce the build. External preparation of the build host such as installing PPAs or other configuration could occur before snapcraft is invoked. See for example https://forum.snapcraft.io/t/yamls-for-snaps-built-using-ppas/6824

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.