| 2018-07-10 13:02:42 |
Jamie Strandboge |
bug |
|
|
added bug |
| 2018-07-10 13:12:53 |
Daniel Manrique |
affects |
software-center-agent |
snapstore |
|
| 2018-07-12 23:09:15 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2018-07-24 15:33:31 |
Natalia Bidart |
snapstore: status |
New |
Triaged |
|
| 2018-07-24 15:33:34 |
Natalia Bidart |
snapstore: importance |
Undecided |
Medium |
|
| 2018-07-24 15:37:52 |
Natalia Bidart |
description |
I remember talking about this a number of times but when I looked for a bug, I couldn't find one.
Knowing the provenance of a snap revision can be a key component in trusting a snap and its publisher. It has always been planned that when we know where a snap came from (eg, an LP build, etc) the store would record the build log link in its database. Once it is in the database:
* the store could provide a link for the revision of the snap (eg, at https://dashboard.snapcraft.io/snaps/SNAPNAME/revisions/NNN/
* an API could be exposed so that a user can obtain the build log url
* snapd could at some point do interesting things with this information such as display the build log url with snap info, offer controls to the user to only allow installs/refreshes if a public build log is available, etc
This is particularly useful for the open source community for all the reasons why Linux distributions make their build logs public (indeed, just today I heard again "if only I could examine the build, I might be able to better trust the snap"). This is somewhat useful as a reviewer (though admittedly, we focus on the publisher, not the contents of the snap) and is one of the steps towards controls for enforcing constraints on the use of classic (https://bugs.launchpad.net/software-center-agent/+bug/1657825). |
I remember talking about this a number of times but when I looked for a bug, I couldn't find one. Crossposted with the form at: https://forum.snapcraft.io/t/display-provenance-of-snap-when-it-is-available/6330/2
Knowing the provenance of a snap revision can be a key component in trusting a snap and its publisher. It has always been planned that when we know where a snap came from (eg, an LP build, etc) the store would record the build log link in its database. Once it is in the database:
* the store could provide a link for the revision of the snap (eg, at https://dashboard.snapcraft.io/snaps/SNAPNAME/revisions/NNN/
* an API could be exposed so that a user can obtain the build log url
* snapd could at some point do interesting things with this information such as display the build log url with snap info, offer controls to the user to only allow installs/refreshes if a public build log is available, etc
This is particularly useful for the open source community for all the reasons why Linux distributions make their build logs public (indeed, just today I heard again "if only I could examine the build, I might be able to better trust the snap"). This is somewhat useful as a reviewer (though admittedly, we focus on the publisher, not the contents of the snap) and is one of the steps towards controls for enforcing constraints on the use of classic (https://bugs.launchpad.net/software-center-agent/+bug/1657825). |
|
| 2018-07-24 15:37:59 |
Natalia Bidart |
description |
I remember talking about this a number of times but when I looked for a bug, I couldn't find one. Crossposted with the form at: https://forum.snapcraft.io/t/display-provenance-of-snap-when-it-is-available/6330/2
Knowing the provenance of a snap revision can be a key component in trusting a snap and its publisher. It has always been planned that when we know where a snap came from (eg, an LP build, etc) the store would record the build log link in its database. Once it is in the database:
* the store could provide a link for the revision of the snap (eg, at https://dashboard.snapcraft.io/snaps/SNAPNAME/revisions/NNN/
* an API could be exposed so that a user can obtain the build log url
* snapd could at some point do interesting things with this information such as display the build log url with snap info, offer controls to the user to only allow installs/refreshes if a public build log is available, etc
This is particularly useful for the open source community for all the reasons why Linux distributions make their build logs public (indeed, just today I heard again "if only I could examine the build, I might be able to better trust the snap"). This is somewhat useful as a reviewer (though admittedly, we focus on the publisher, not the contents of the snap) and is one of the steps towards controls for enforcing constraints on the use of classic (https://bugs.launchpad.net/software-center-agent/+bug/1657825). |
I remember talking about this a number of times but when I looked for a bug, I couldn't find one. Crossposted with the form at: https://forum.snapcraft.io/t/display-provenance-of-snap-when-it-is-available/6330
Knowing the provenance of a snap revision can be a key component in trusting a snap and its publisher. It has always been planned that when we know where a snap came from (eg, an LP build, etc) the store would record the build log link in its database. Once it is in the database:
* the store could provide a link for the revision of the snap (eg, at https://dashboard.snapcraft.io/snaps/SNAPNAME/revisions/NNN/
* an API could be exposed so that a user can obtain the build log url
* snapd could at some point do interesting things with this information such as display the build log url with snap info, offer controls to the user to only allow installs/refreshes if a public build log is available, etc
This is particularly useful for the open source community for all the reasons why Linux distributions make their build logs public (indeed, just today I heard again "if only I could examine the build, I might be able to better trust the snap"). This is somewhat useful as a reviewer (though admittedly, we focus on the publisher, not the contents of the snap) and is one of the steps towards controls for enforcing constraints on the use of classic (https://bugs.launchpad.net/software-center-agent/+bug/1657825). |
|
| 2018-07-25 18:59:42 |
Maximiliano Bertacchini |
snapstore: status |
Triaged |
In Progress |
|
| 2018-07-26 21:28:13 |
Maximiliano Bertacchini |
bug task added |
|
software-center-agent |
|
| 2018-07-26 21:28:25 |
Maximiliano Bertacchini |
software-center-agent: status |
New |
Fix Released |
|
| 2018-07-26 21:28:34 |
Maximiliano Bertacchini |
snapstore: status |
In Progress |
Triaged |
|
| 2018-07-26 21:28:38 |
Maximiliano Bertacchini |
software-center-agent: importance |
Undecided |
Medium |
|
| 2018-07-26 21:28:52 |
Maximiliano Bertacchini |
snapstore: status |
Triaged |
In Progress |
|
| 2018-07-26 21:28:57 |
Maximiliano Bertacchini |
software-center-agent: assignee |
|
Maximiliano Bertacchini (maxiberta) |
|
| 2018-07-26 21:28:59 |
Maximiliano Bertacchini |
snapstore: assignee |
|
Maximiliano Bertacchini (maxiberta) |
|
| 2018-08-28 21:25:02 |
Maximiliano Bertacchini |
snapstore: assignee |
Maximiliano Bertacchini (maxiberta) |
|
|
| 2018-08-28 21:25:06 |
Maximiliano Bertacchini |
snapstore: status |
In Progress |
Confirmed |
|
| 2018-12-17 17:52:05 |
Adam Collard |
snapstore: assignee |
|
Maximiliano Bertacchini (maxiberta) |
|
| 2019-01-21 19:49:03 |
Maximiliano Bertacchini |
snapstore: status |
Confirmed |
In Progress |
|
| 2019-01-28 15:29:09 |
Maximiliano Bertacchini |
snapstore: status |
In Progress |
Confirmed |
|
| 2019-03-08 06:59:12 |
William Grant |
tags |
|
feature |
|
