Make security updates discoverable fast and easy

[erikvanoosten]

Security updates should be visible as soon as possible. Preferably within minutes after they are published people should have all the information needed to start upgrading.

I think getting information about security updates should be the major driver in Adapt's target of discovering new artifacts.

One way to do this is by clearly printing the security updates during each 'build'.

[freekh]

Hey! Yeah, when I have been talking around and this is quite a common requirement. Often this is solved by using a version scheme and version ranges: 1.0.1 is a security release of 1.0. The dependency would then have a version range like this; (1.0.x[. or similar.

I am on the fence about version ranges, but I think adept definitely has to support the use case you are talking about. The problem with version ranges is that it breaks our number one tenant - being reproducible.

Printing the security updates would typically be the build tool that is responsible, but it has to be possible for adept to store the information that this is in fact a security update and retrieve the modules that are security updates.

Just so it is clear I am not sure about the best way of solving this - it would be great to get your feedback!

One way would be to have support for a query mechanism where you can search for version ranges and attributes key/value pairs. Imagine you have already resolved the dependency graph you need. Then the build tool would check for all modules for modules that match the following query: adept.query("my:module:[1.x)", "security-update" -> true) The build tool should be able to calculate calculate the coordinates. This would be purely by convention so you could imagine other querying for other attributes as well. WDYT?

[erikvanoosten]

Actually, there is an application that tries to do something in this direction. I thought they had a clever format in use, but it turns out its just markdown in the repository's notes directory. I am talking about http://implicit.ly/ and http://ls.implicit.ly. The application that goes with it is https://github.com/n8han/herald.

The structure is simple. For example:

herald/
  notes/
    0.1.0.markdown
    0.1.1.markdown
    about.markdown

Now this is too simple for Adapt's purposes. Somehow you need to know some structured metadata. I propose to use a yaml block that preceds the content in each markdown file. Same as Jekyll (http://jekyllrb.com/) does it. Here is what 0.1.1.markdown would look like:

---
blurp: Security fix
security-update: true
tag: version-0.1.1
---
# Security update
A security fix was merged ...

Anyway, indicating that a release is a security release will not work. It will simply not be adopted.

BTW, I would like to warn against adopting generic attributes for selecting. If it works like that in the background fine, but don't over do it. I would not like to get a osgi-like system.

[freekh]

Alright, so I hope I am getting this right: basically you want it to be able to tag security updates in the metadata and you are warning against generic attributes for this. This is definitely feasible - let us leave this ticket open and close it when I can show it working :) (I hope I am not misunderstanding you - if that is the case please feel free to correct me :)

Also, not entirely related, I think it would be cool to have a service as implicitly (or perhaps make it support adept) where you can subscribe to/follow dependencies and get security updates on mail or by other notifications.