Remove vendor from meta

[Daniel Holbach]

Snapcraft should ensure vendor is of form "Jane Doe <email address hidden>" otherwise click-reviewers-tools will reject it.

[Sergio Schvezov (sergiusens)]

On Tue, Oct 27, 2015 at 9:37 AM, Daniel Holbach <email address hidden>
wrote:

> Public bug reported:
>
> Snapcraft should ensure vendor is of form "Jane Doe <email address hidden>"
> otherwise click-reviewers-tools will reject it.
>

After talking to beuno, I thought we said we'd fix it in the review tools
instead.

[Daniel Holbach (dholbach)]

I personally would fix it as early in the process as possible. Let's say you upload a 200M .snap to the store just to find out that you got the email address of the vendor wrong, that would be a bit disappointing, no? Or we could make c-r-t run after the snapcraft build...?

[Mark Shuttleworth (sabdfl)]

Vendor should not be in snapcraft.yaml because that makes it hard to
branch-and-build.

Vendor should be validated by upload tools prior to upload.

Mark

On 27/10/15 22:30, Daniel Holbach wrote:
> I personally would fix it as early in the process as possible. Let's say
> you upload a 200M .snap to the store just to find out that you got the
> email address of the vendor wrong, that would be a bit disappointing,
> no? Or we could make c-r-t run after the snapcraft build...?
>

[James Tait (jamestait)]

There's this question on askubuntu relating directly to this validation:

  http://askubuntu.com/questions/417351/what-does-lint-maintainer-format-mean

If we change the behaviour of click-reviewer-tools, we should also update the information there - with Snapcraft, maybe it's already out of date?

[Oliver Grawert (ogra)]

@mark, where would Vendor come from if not from the snapcraft.yaml (which might be the only metadata file that is there imagining all content comes from remote trees) ? only from the store ?

[Mark Shuttleworth (sabdfl)]

  ~/.snapcraft

It makes more sense to have it as a home-dir config for snapcraft, so
that every snap you build (regardless of where the code came from) shows
up as your vendor.

On the other hand, the snap-id (coming soon) should be in the
snapcraft.yaml because that's the same for everybody who builds it,
typically.

Mark

[Daniel Holbach (dholbach)]

For guessing the email we could try to find out DEBEMAIL or `bzr whoami`, but in some cases, especially for commercial projects, vendor email != individual-maintainer email.

[Oliver Grawert (ogra)]

i guess then having some kind of "first-start wizard" in place when you use snapcraft for the first time might make sense. to set up the vendor or snap-id and perhaps further global settings that snapcraft will consume (this might be more user friendly than just spilling an error like "please set your vendor ID in ~/.snapcraft")

[Mark Shuttleworth (sabdfl)]

On 29/10/15 17:50, Daniel Holbach wrote:
> For guessing the email we could try to find out DEBEMAIL or `bzr
> whoami`, but in some cases, especially for commercial projects, vendor
> email != individual-maintainer email.

Please don't guess, just require it to be in ~/.snapcraft and validate
it there. Simpler, cleaner, explicit.

Mark

[Mark Shuttleworth (sabdfl)]

In fact, let's make ~/.snapcraft/ a directory:

 ~/.snapcraft/config
 ~/.snapcraft/build_key.pem

etc.

Mark

[John Lenton (chipaca)]

${XDG_CONFIG_HOME:-$HOME/.config}/snapcraft/ ?

[Leo Arias (elopio)]

Moved to https://github.com/ubuntu-core/snapcraft/issues/47

[Zygmunt Krynicki (zyga)]

Any chance we could use ~/.config/snapcraft for that?

On Fri, Oct 30, 2015 at 2:21 AM, Mark Shuttleworth <email address hidden> wrote:
>
> In fact, let's make ~/.snapcraft/ a directory:
>
> ~/.snapcraft/config
> ~/.snapcraft/build_key.pem
>
> etc.
>
> Mark
>
>
> --
> snappy-internal mailing list
> <email address hidden>
> Modify settings or unsubscribe at: https://lists.canonical.com/mailman/listinfo/snappy-internal
>

[Mark Shuttleworth (sabdfl)]

On 05/11/15 13:09, Zygmunt Krynicki wrote:
> Any chance we could use ~/.config/snapcraft for that?

Fine by me, box-checker ;)

Mark

[Sergio Schvezov (sergiusens)]

After discussing with Gustavo and Martin we agreed to remove all traces of `vendor` and implement what comes for 16.04, it is an unused attribute in 15.04

[Jamie Strandboge (jdstrand)]

It is actually used to verify 'bus-name' for DBus framework services. Eg, if the vendor is <email address hidden>, then we check if the bus-name is 'com.example' and if it doesn't match, issue a warning. This is to help with frameworks being coinstallable. What will be implemented for 16.04?

[Sergio Schvezov (sergiusens)]

Gustavo and Martin, Jaime raises an interesting thing that is done with vendor; this makes the removal of vendor a tad more complicated.

Personally I'd remove the check entirely as the check is enforced locally (within the snap) but not against the store (store doesn't check if the 'vendor' is a valid vendor for the account use to upload the snap).

We do need to iron out a plan for 16.04 though.

[Gustavo Niemeyer (niemeyer)]

For 16.04 we're having a look not only at vendor but at the whole metadata that is included in the snap. Sergio has kindly prepared a document that highlights what is currently in use, and we're starting to draft a list of changes we intend to do in time for 16.04 there:

https://docs.google.com/document/d/1QbPOoGBEEZ5qFTYWSKLVUCw4EQvQ0eBWTSqmhU9Bj0I/edit?disco=AAAAAiYPg6o

Coming back to vendor, the term is incorrect according to agreements we've made in the last few months. This is actually either a snap publisher, or a snap developer. Most likely the latter. Besides the name, it also feels like we have issues in terms of the accepted values. If this is a snap developer, we should most probably have the actual developer name there, because that's what all of snappy will be looking at. As a practical example, if we have "apache.beuno", it means we have the "apache" snap from the "beuno" snap developer, so what we should have in that file is "beuno", not a name or an email.

With all of that said, it's not even clear that we need that information in the snap, or whether the information we have from assertions would be more interesting. So my initial recommendation was to drop that data altogether until we know how exactly how we'll be using it, so that we can have a more informed conversation that isn't just based on suppositions.

With regards to the use case mentioned above, I apologize for not being aware of these details, but at least what was said above sounds a bit curious. We cannot use someone's email to determine whether they can access something or not. What would we do with people that have a gmail email? This feels so unreasonable that I'm probably missing important points of that issue, so can you expand on how that information is being used and what the intention is for the near future?

[Jamie Strandboge (jdstrand)]

> "then we check if the bus-name is 'com.example'"

This should have read "then we check if the bus-name is 'com.example.<pkgname>'.

Do keep in mind 'bus-name' is only available to framework services, and frameworks always undergo review in the public store.

Consider the following yaml:
name: foo
type: framework
vendor: Some One <email address hidden>
services:
  - name: bar
    bus-name: com.canonical.foo

The idea behind the current review tools checks is that *if* the bus-name matches the reverse domain name + .<pkgname> (note, DBus bus-names typically use reverse domain names) then the bus-name can at least be under the control of the vendor's DBus namespace. The review tools spit out a warning instead of an error if they go outside of this since there are legitimate reasons to go outside of the vendor's namespace (eg, the current network-manager framework). As you pointed out, this does not work for @gmail.com addresses, but, we've previously asserted that we don't expect there to be many frameworks and since all frameworks go through review anyway, the current check is more guidance on how to namespace your DBus bus-name. We haven't been able to do a more thorough check because the store (currently) doesn't provide the review tools with anything more than the snap itself.

Can the check be removed? Certainly. We could adjust the review tools checks to instead of looking at the vendor, instead just see if the bus-name ends with '.<pkgname>' which would preserve coinstallability. The main point of my previous comment was simply to provide additional information on where the current 'vendor' field is consulted.

[Gustavo Niemeyer (niemeyer)]

Thanks for the detailed coverage, Jamie.

Considering that the check is advisory, and that it is both known to not work in certain cases, and has imperfect heuristics (emails change), I would indeed recommend dropping the check for the time being.

[Jamie Strandboge (jdstrand)]

The review tools now no longer do any formatting checks for vendor or look at vendor when verifying "bus-name". I've asked the store guys to sync this.

[Leo Arias (elopio)]

Snapcraft fix in https://github.com/ubuntu-core/snapcraft/pull/154

[Jamie Strandboge (jdstrand)]

This was fixed in 0.35.