dan2k3k4 → credited naderman → .
Oof and looking at sources in your response. The "name" there is not the name of the advisory at the source, but rather the name of the source. So something like "Drupal" if you are the authority administrating those remoteIds.
I think it's important to add too, that these advisories for different packages must use different advisoryIds, so you should not return different names for the same advisory depending on how some API request arrives. Instead you really do need to define one advisory with its own id for each package that has a security issue. You can refer to the report that's the basis for all of them by its shared identifier in the sources remoteId section. So for submodules, you probably want to at least append the submodule name or something to the advisory id if not define a new numbering system for these.
So a first update on this as we're going through the advisories functionality again to make sure that different 3rd party repo implementations don't cause problems:
https://github.com/composer/composer/commit/a29acbdd2ed087940ed12447fe7d...
The query-all option has been dropped, it was ignored anyways. The security advisories API is now a requirement if you don't provide a list of available-packages or an available-packages-pattern to restrict search space for advisories in p2 files. Since packages.drupal.org/8/packages.json specifies "available-package-patterns" this particular requirement does not require the API implementation for this repo right now.
I'll post again when/if there are more updates that may impact this repo.
@cmlara I had a conversation with Jordi about those tickets before creating the issue here. Generally I think there are some problems with how that was implemented and in hindside I don't think it should have happened that way.
So for now the way to fully get it working correctly is with the API as described here, and I think @drumm may be right about the reason for the issue that popped up.
That said I'd like to revisit if there is a way to avoid implementing the API endpoint with Jordi in January and see if maybe there's a way to get the p2 mechanism working fully, maybe through modifying what the changes feed contains, or providing some other static discoverability mechanism for advisories, that the p2 files currently lack. Think we also need to take another look at consistency of Composer behavior about loading p2 files for advisories from lower priority repositories despite dependency resolution intentionally skipping them.
Implementation looks fine to me as far as I can tell that without knowing all the surrounding code, and API looks to work as expected. Thanks very much for the speedy implementation here as well!
Only question I have is in how far you have strong ordering guarantees there, e.g. when/how does the last updated timestamp for a package get set? If I get a response with a specific timestamp from the changes json, how likely is a change going to be written for that same or the previous second right afterwards due to either multiple machines processing this with slightly different clocks, or a process getting a timestamp at the beginning but running for a second or multiple before saving the data?
Implementation looks fine to me as far as I can tell that without knowing all the surrounding code, and API looks to work as expected. Thanks very much for the speedy implementation here!
naderman → created an issue.
naderman → created an issue.
Bit late, but thanks very much, Neil! :-D