Re: ANN: snapcraft 2.28 has been released

[Neal Gompa]

On Sat, Apr 1, 2017 at 5:22 PM, John Lenton <john.len...@canonical.com> wrote:
> On 31 March 2017 at 21:52, Neal Gompa <ngomp...@gmail.com> wrote:
>> we
>> definitely don't want to use less than SHA256 for snaps.
>
> note snaps use sha3-384 currently; the above discussion is, as I
> understand it, about snapcraft checking upstream checksums at build
> time.
>

Sure, but it's just as important that the inputs can be trusted for a
given snap created by snapcraft, and allowing people to choose weak
algorithms is against that.



-- 
真実はいつも一つ！/ Always, there's only one truth!

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Snap package licenses

[Neal Gompa]

Ah, you're talking about the full SPDX spec. That is a completely
different beast. I don't know of anyone using that right now...

On Tue, Jan 31, 2017 at 2:30 PM, Gustavo Niemeyer <gust...@niemeyer.net> wrote:
> Yes, that's the custom and/or rule I mentioned. This is not the SPDX license
> expression format:
>
> https://spdx.org/spdx-specification-21-web-version
>
>
> On Tue, Jan 31, 2017 at 5:22 PM, Neal Gompa <ngomp...@gmail.com> wrote:
>>
>> No, you're not missing something. AppStream doesn't really have a
>> great way to represent custom licenses. But license expressions are
>> supported, as you can see in this example[1]. I suspect the "proper"
>> way to handle it would be to have the license bundled in the metadata
>> when "Custom" or "Proprietary" is used, so that the resource is
>> available for review prior to installing. With the standardized
>> licenses, usually the software centers render hyperlinks that users
>> can click to see the terms.
>>
>> I'd potentially argue that BSD and MIT licenses would probably need to
>> be handled the same way, given that copyright owners are declared in
>> the license text.
>>
>> [1]:
>> https://gitlab.com/osslugaru/lugaru/blob/master/Dist/Linux/lugaru.appdata.xml
>>
>> On Tue, Jan 31, 2017 at 2:03 PM, Gustavo Niemeyer <gust...@niemeyer.net>
>> wrote:
>> >
>> > Using the license ids from SPDX seems straightforward, and that's what
>> > AppStream seems to encourage. But it doesn't mention support for SPDX
>> > license expressions (has a custom and/or rule), or what to do on custom
>> > licenses. So the harmony seems shallow, if you see what I mean. Or am I
>> > missing something?
>> >
>> > On Tue, Jan 31, 2017 at 4:24 PM, Neal Gompa <ngomp...@gmail.com> wrote:
>> >>
>> >> SUSE has their own list of non-standard references[1], but my
>> >> understanding is that SPDX is working on making this a bit more
>> >> flexible in this regard. This was one of the reasons we haven't
>> >> switched to it in Fedora (the other being the mismatch of BSD/MIT tags
>> >> to SPDX equivalents). AppStream metainfo files shipped with software
>> >> include the SPDX license tags[2].
>> >>
>> >> One of the reasons I personally favor the Fedora tags more is because
>> >> it's not obnoxious with dealing with classes of licenses. However,
>> >> AppStream does mandate SPDX, and harmonizing snap metadata with
>> >> AppStream metadata makes it easier to keep things sane and in sync,
>> >> especially if developers want to use their metainfo files as input for
>> >> generating parts of the snap metadata. Of course, maintaining harmony
>> >> does not imply that SPDX license tags need to be used in snap data,
>> >> only that some kind of automatic mapping from SPDX to another system
>> >> is available. Richard Hughes' appstream-glib (used by GNOME/Ubuntu
>> >> Software) has such a mechanism for going from Fedora/SUSE-classic to
>> >> SPDX[3], and the other way around is considerably simpler.
>> >>
>> >> [1]: https://github.com/openSUSE/obs-service-format_spec_file
>> >> [2]:
>> >>
>> >> https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html
>> >> [3]:
>> >>
>> >> https://github.com/hughsie/appstream-glib/blob/master/libappstream-glib/as-utils.c#L555
>> >>
>> >> On Tue, Jan 31, 2017 at 11:43 AM, Gustavo Niemeyer
>> >> <gustavo.nieme...@canonical.com> wrote:
>> >> > That's an interesting idea.  Is there a known repository for license
>> >> > texts
>> >> > which are not standard?  I see SPDX uses a LicenseRef- kind of
>> >> > reference, but it's not clear what that is referencing. Just another
>> >> > field
>> >> > inside the XML in the case of AppStream, I suppose?
>> >> >
>> >> > On Thu, Jan 26, 2017 at 9:58 PM, Neal Gompa <ngomp...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth <m...@ubuntu.com>
>> >> >> wrote:
>> >> >> >
>> >> >> > We should allow a plaintext field there for this situation. Yes,
>> >> >> > go
>> >> >> > ahead with "Other open source".
>> >> >> >
>> >> >&g

Re: Snap package licenses

[Neal Gompa]

No, you're not missing something. AppStream doesn't really have a
great way to represent custom licenses. But license expressions are
supported, as you can see in this example[1]. I suspect the "proper"
way to handle it would be to have the license bundled in the metadata
when "Custom" or "Proprietary" is used, so that the resource is
available for review prior to installing. With the standardized
licenses, usually the software centers render hyperlinks that users
can click to see the terms.

I'd potentially argue that BSD and MIT licenses would probably need to
be handled the same way, given that copyright owners are declared in
the license text.

[1]: 
https://gitlab.com/osslugaru/lugaru/blob/master/Dist/Linux/lugaru.appdata.xml

On Tue, Jan 31, 2017 at 2:03 PM, Gustavo Niemeyer <gust...@niemeyer.net> wrote:
>
> Using the license ids from SPDX seems straightforward, and that's what
> AppStream seems to encourage. But it doesn't mention support for SPDX
> license expressions (has a custom and/or rule), or what to do on custom
> licenses. So the harmony seems shallow, if you see what I mean. Or am I
> missing something?
>
> On Tue, Jan 31, 2017 at 4:24 PM, Neal Gompa <ngomp...@gmail.com> wrote:
>>
>> SUSE has their own list of non-standard references[1], but my
>> understanding is that SPDX is working on making this a bit more
>> flexible in this regard. This was one of the reasons we haven't
>> switched to it in Fedora (the other being the mismatch of BSD/MIT tags
>> to SPDX equivalents). AppStream metainfo files shipped with software
>> include the SPDX license tags[2].
>>
>> One of the reasons I personally favor the Fedora tags more is because
>> it's not obnoxious with dealing with classes of licenses. However,
>> AppStream does mandate SPDX, and harmonizing snap metadata with
>> AppStream metadata makes it easier to keep things sane and in sync,
>> especially if developers want to use their metainfo files as input for
>> generating parts of the snap metadata. Of course, maintaining harmony
>> does not imply that SPDX license tags need to be used in snap data,
>> only that some kind of automatic mapping from SPDX to another system
>> is available. Richard Hughes' appstream-glib (used by GNOME/Ubuntu
>> Software) has such a mechanism for going from Fedora/SUSE-classic to
>> SPDX[3], and the other way around is considerably simpler.
>>
>> [1]: https://github.com/openSUSE/obs-service-format_spec_file
>> [2]:
>> https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html
>> [3]:
>> https://github.com/hughsie/appstream-glib/blob/master/libappstream-glib/as-utils.c#L555
>>
>> On Tue, Jan 31, 2017 at 11:43 AM, Gustavo Niemeyer
>> <gustavo.nieme...@canonical.com> wrote:
>> > That's an interesting idea.  Is there a known repository for license
>> > texts
>> > which are not standard?  I see SPDX uses a LicenseRef- kind of
>> > reference, but it's not clear what that is referencing. Just another
>> > field
>> > inside the XML in the case of AppStream, I suppose?
>> >
>> > On Thu, Jan 26, 2017 at 9:58 PM, Neal Gompa <ngomp...@gmail.com> wrote:
>> >>
>> >> On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth <m...@ubuntu.com>
>> >> wrote:
>> >> >
>> >> > We should allow a plaintext field there for this situation. Yes, go
>> >> > ahead with "Other open source".
>> >> >
>> >>
>> >> It would probably make sense to support SPDX license tags and
>> >> expressions[1]. This is used in AppStream, so a great amount of
>> >> software is already classified in this manner. Furthermore, openSUSE
>> >> uses SPDX tags for their license metadata for packages, and Debian
>> >> uses a subset of it as part of the copyright file structure in Debian
>> >> Source Control packaging.
>> >>
>> >> While we in Fedora use our own license tag list[2] that predates SPDX
>> >> (used by a great deal of Linux distributions), we maintain a mapping
>> >> to SPDX for AppStream support.
>> >>
>> >> Having verifiable license information (either Fedora style or SPDX
>> >> style) is also useful for ensuring things are "compatible" or
>> >> "desired" on a system, depending on whatever preference you may have.
>> >>
>> >> [1]: https://spdx.org/licenses/
>> >> [2]:
>> >> https://fedoraproject.org/wiki/Licensing:Main#Software_License_List
>> >>
>&g

Re: Snap package licenses

[Neal Gompa]

SUSE has their own list of non-standard references[1], but my
understanding is that SPDX is working on making this a bit more
flexible in this regard. This was one of the reasons we haven't
switched to it in Fedora (the other being the mismatch of BSD/MIT tags
to SPDX equivalents). AppStream metainfo files shipped with software
include the SPDX license tags[2].

One of the reasons I personally favor the Fedora tags more is because
it's not obnoxious with dealing with classes of licenses. However,
AppStream does mandate SPDX, and harmonizing snap metadata with
AppStream metadata makes it easier to keep things sane and in sync,
especially if developers want to use their metainfo files as input for
generating parts of the snap metadata. Of course, maintaining harmony
does not imply that SPDX license tags need to be used in snap data,
only that some kind of automatic mapping from SPDX to another system
is available. Richard Hughes' appstream-glib (used by GNOME/Ubuntu
Software) has such a mechanism for going from Fedora/SUSE-classic to
SPDX[3], and the other way around is considerably simpler.

[1]: https://github.com/openSUSE/obs-service-format_spec_file
[2]: https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html
[3]: 
https://github.com/hughsie/appstream-glib/blob/master/libappstream-glib/as-utils.c#L555

On Tue, Jan 31, 2017 at 11:43 AM, Gustavo Niemeyer
<gustavo.nieme...@canonical.com> wrote:
> That's an interesting idea.  Is there a known repository for license texts
> which are not standard?  I see SPDX uses a LicenseRef- kind of
> reference, but it's not clear what that is referencing. Just another field
> inside the XML in the case of AppStream, I suppose?
>
> On Thu, Jan 26, 2017 at 9:58 PM, Neal Gompa <ngomp...@gmail.com> wrote:
>>
>> On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth <m...@ubuntu.com>
>> wrote:
>> >
>> > We should allow a plaintext field there for this situation. Yes, go
>> > ahead with "Other open source".
>> >
>>
>> It would probably make sense to support SPDX license tags and
>> expressions[1]. This is used in AppStream, so a great amount of
>> software is already classified in this manner. Furthermore, openSUSE
>> uses SPDX tags for their license metadata for packages, and Debian
>> uses a subset of it as part of the copyright file structure in Debian
>> Source Control packaging.
>>
>> While we in Fedora use our own license tag list[2] that predates SPDX
>> (used by a great deal of Linux distributions), we maintain a mapping
>> to SPDX for AppStream support.
>>
>> Having verifiable license information (either Fedora style or SPDX
>> style) is also useful for ensuring things are "compatible" or
>> "desired" on a system, depending on whatever preference you may have.
>>
>> [1]: https://spdx.org/licenses/
>> [2]: https://fedoraproject.org/wiki/Licensing:Main#Software_License_List
>>
>> --
>> 真実はいつも一つ！/ Always, there's only one truth!
>>
>> --
>> Snapcraft mailing list
>> Snapcraft@lists.snapcraft.io
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/snapcraft
>
>
>
>
> --
> gustavo @ http://niemeyer.net
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snapcraft
>



-- 
真実はいつも一つ！/ Always, there's only one truth!

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Snap package licenses

[Neal Gompa]

On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth  wrote:
>
> We should allow a plaintext field there for this situation. Yes, go
> ahead with "Other open source".
>

It would probably make sense to support SPDX license tags and
expressions[1]. This is used in AppStream, so a great amount of
software is already classified in this manner. Furthermore, openSUSE
uses SPDX tags for their license metadata for packages, and Debian
uses a subset of it as part of the copyright file structure in Debian
Source Control packaging.

While we in Fedora use our own license tag list[2] that predates SPDX
(used by a great deal of Linux distributions), we maintain a mapping
to SPDX for AppStream support.

Having verifiable license information (either Fedora style or SPDX
style) is also useful for ensuring things are "compatible" or
"desired" on a system, depending on whatever preference you may have.

[1]: https://spdx.org/licenses/
[2]: https://fedoraproject.org/wiki/Licensing:Main#Software_License_List

-- 
真実はいつも一つ！/ Always, there's only one truth!

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Snappy evolution

[Neal Gompa]

 On Sun, Jan 8, 2017 at 2:26 PM, Aleix Pol  wrote:
> Hi everyone,
> Last Snappy meeting we discussed several subjects and I would like to
> know what's the status, hence this e-mail.
> - Usage of snappy in random Linux systems: Red Hat et al (Fedora,
> CentOS), random GNU/Linux kernels (e.g. ArchLinux and Android).

This is not working.

SELinux support is missing within snapd, and I'm still playing
whack-a-mole with the SELinux policy module[0] I've been working on.

Unfortunately, the correct way to handle this is something I'm simply
not skilled at doing, since it requires fundamentally comprehensive
understanding of snapd and conceptual understanding of SELinux as a
MAC and how to use it through libselinux in the manner needed by
snapd. While I have the conceptual understanding of SELinux, I do not
have the other two pieces. The concepts of SELinux MAC and snapd's
security model do mostly line up, from what I can tell, so it's just a
matter of someone with understanding of both bridging the gap.

CentOS, Fedora, and Android use SELinux, so this is a prerequisite for
making Snappy work in a useful, secure manner.

Arch Linux has no MAC by default, though the community prefers SELinux
and offers it as a supported-ish option (see Arch Hardened), likewise
for Gentoo (see Gentoo Hardened).

In addition, we're still missing some kind of way to swap default core
snaps and have a concept of a "base" snap so that distributions can
build snaps from their own code. I wrote code for making core snaps
based on Fedora, Mageia, or openSUSE[1], but there's still no way for
me to force snapd to use a different core snap.

There's also still work to be done from the Snapcraft side to support
different distributions, too. See the snapcraft bug[2] for details.

[0]: https://gitlab.com/Conan_Kudo/snapcore-selinux
[1]: https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap
[2]: https://bugs.launchpad.net/snapcraft/+bug/1602258

> - Some discussed AppStream semantics introduction for integration in
> Software Centers.
>

As far as I know, I don't think anything has happened on this front
since we discussed at the sprint.




-- 
真実はいつも一つ！/ Always, there's only one truth!

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Deploying private snap store

[Neal Gompa]

On Fri, Dec 16, 2016 at 4:59 AM, James Tait  wrote:
> On 16 December 2016 at 06:56, Luther Goh Lu Feng  wrote:
>>
>> I am looking for software to roll out my own snap store. I am under the
>> impression that these are the 2 to look at:
>>
>> - https://github.com/noise/snapstore/
>> - https://github.com/snapcore/snapweb
>>
>> Can I confirm please? Any others I missed and which is better? Thanks.
>>
> That’s correct. See also the documentation at
> https://search.apps.ubuntu.com/docs/
>

That's not quite correct. Snapweb is a web interface for managing the
local snapd instance. It still needs a store. To the best of my
knowledge, the snapstore project is the only known open source
implementation of the snapd repository system.



-- 
真実はいつも一つ！/ Always, there's only one truth!

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft