Aloha,
I would like to bring up another topic:
collaboration on security
One area here specifically I am thinking of here are policies for how to deal with security issues. This here is for example the Symfony2 process:
http://symfony.com/doc/current/contributing/code/security.html
On top of that I would also like to bring up the security advisories database:
http://fabien.potencier.org/article/74/the-php-security-advisories-database
Regarding the latter part of your message, I am currently working on a UI which allows composer management from an admin UI and I intend to make a lot of the code re-usable. Saying this, this is rather a separate issue/discussion from the one in regards to security?
On your primary point of security, I too am slightly unsure of what your actual proposal is beyond an initiative to get FIG members to all centralise their security vulnerabilities in one place (the FriendsOfPHP Security Advisories Repo).
I cannot really see the usefulness of an agreement of how to handle security vulnerabilities except maybe as something new OS projects can look to (Best Practices Recommendation) when considering how they should handle security vulnerabilities as existing projects all have their well established ways of handling security issues which differ in some areas (Release ASAP after identifying issue and patching vs Release Windows [Similar to Microsoft's Patch Tuesday]) but generally all agree on the good core foundations which Paddy outlined.
I do agree however that a centralised way of handing security advisories is a good idea but this already exists in the form of the Security Advisories Repo, I think the mission should simply be to get more people to make use of it?
Try to respond even something to the reporter, probably anything is better than completely radio silence.
When we last discussed this, my thinking was that we should establish a feed-capable format for recording SAs, and then projects should "conspicuously publish" a URL where SAs can be retrieved from. For smaller projects that would likely be just a file in their GitHub repo, or some 3rd party aggregator that will host it for them. For larger projects or meta projects (eg, Drupal) that would have a larger number of SAs because they cover many projects, they could have an actual feed. In either case, someone could poll the URL and check their own project's dependencies, or an aggregator like Sensio could do so, or whatever. Let the market sort that part out, as long as it's just a URL that returns some known format our job is done.
In practice I figure "conspicuously publish" would probably turn into a key in composer.json, but that's not something we'd require.
The advantage of a feed-capable format is push-notifications. It would be great if we could support some sort of pubsub mechanism for aggregators. It's an optional piece, but could be useful to avoid pinging the world to death. :-)
I don't think a central authoritative repository of SAs is wise, if for no other reason then "who the hell is going to maintain that?" I am not volunteering. :-)
I think we're saying the same thing. We just say "make this URL available in some way". Whatever centralization and aggregation that then happens, happens. If that's Packagist, cool. If it's not Packagist, also cool. Sensio or someone like that could encourage people to just register their known URL with them and take it from there. That's out of our hands. We just say "provide a URL where one can get X data".
On 30 October 2014 22:04, Larry Garfield <la...@garfieldtech.com> wrote:I think we're saying the same thing. We just say "make this URL available in some way". Whatever centralization and aggregation that then happens, happens. If that's Packagist, cool. If it's not Packagist, also cool. Sensio or someone like that could encourage people to just register their known URL with them and take it from there. That's out of our hands. We just say "provide a URL where one can get X data".Yep, we're on same page. Only clarification would be what I call discovery which is just addressing how to locate the data based on something simpler, such as the repo URI or main website URL. For repos, it would be likely just be by convention - have an xxx.json or xxx.yaml file. For websites, it may need a meta tag indicating the location of the relevant feed. Mostly this is just help reduce manual intervention by having to take to google or a site search. I could also be going overboard - it's been known to happen ;).
Wouldn't we need the central repository to be something where participating projects can "register" their project, so that the central repository doesn't have to do any discovery (which I think could easily be a dead end)?
Some kind of moderation is also needed (in case someone wants harass the service by submitting bogus details etc., it could be just removed from the central repository).
I'm thinking the "central repository" to be like a web page which displays participating projects' security alerts, possibly with some nice decorations like bug type grouping etc. But all the actual information is coming from the participating projects' own repositories. And maybe the central repository would share details of all the participating projects, so another entity could create same kind of "central repository service". But anyway, I think we need one "central place" where participating projects can register, so they all become "indexed". Does this sound reasonable?
On 31 October 2014 08:17, Timo H <tim...@gmail.com> wrote:Wouldn't we need the central repository to be something where participating projects can "register" their project, so that the central repository doesn't have to do any discovery (which I think could easily be a dead end)?
Some kind of moderation is also needed (in case someone wants harass the service by submitting bogus details etc., it could be just removed from the central repository).
The problem with any central repository is that it would also become a moderator of data. It’s one of the obvious problems with Fabien’s current effort that all vulnerabilities need to be centralised, which means that they need to be moderated. It can never become a free for all resource due to the risk of the incoming reports exceeding the capacity of its moderators (i.e. those with commit authority) to peer review them for accuracy prior to merging.
A decentralised system exports the responsibility back to where it belongs, the projects themselves. The only way to fake/game the system, would be to do something at the project level where it would be self-limited by the project ID (readily verifiable with reference to the git repo URL either locally or via a third party like Packagist).
That doesn’t preclude the existence of central repositories – it just renders them non-essential. They can still play a role documenting vulnerabilities for projects which haven’t opted to use anything suggested here, where moderation and third party tracking DOES then make sense, and where downstream clients actually consuming such data can opt in or out of trusting them as a centralised source. That’s with the implied limitation that data from a specific project will take precedence over data from a centralised source by default (perhaps provide a warning should data conflict so that users can dig deeper and switch trust to the centralised source if its more reliable for a project).
I'm thinking the "central repository" to be like a web page which displays participating projects' security alerts, possibly with some nice decorations like bug type grouping etc. But all the actual information is coming from the participating projects' own repositories. And maybe the central repository would share details of all the participating projects, so another entity could create same kind of "central repository service". But anyway, I think we need one "central place" where participating projects can register, so they all become "indexed". Does this sound reasonable?In a way, we already have a significant number of projects out there pre-indexed by Packagist. Without even implying Packagist have anything to do with security issues, that index can be reused by anyone for other purposes. Before my extended break over the Summer, I was using it myself to conduct a survey of code standards adherence. Note to self: need to finish that...
Given an already public index of project repositories/websites, all you need on top of that is "discovery", a simple set of rules that let you locate the security data based on something like the repo URI.
For projects not registered on Packagist, discovery rules can still apply to however you are including them, e.g. via Composer. If you're not using Composer... We'd need to see specific examples here to identify a treatment.
This makes sense, but I'd still prefer there was one single place where I can go with my web browser and browse security advisories (I think the auto discovery is not ideal here). Or is it just me who finds sites like http://www.cvedetails.com/ practical? ;)
I suppose the point is that the PHP-FIG is not here to implement, but to offer solutions for interoperability that enable interoperable implementations. There may well be some centralised advisory store, but the possibility of its existence, and the shape it takes, will be determined outside of our control.
What is within our control is how the data is presented, how the data can be discovered, and exactly what that data should include. Once it's out there, folk can build anything they want on top of that.
Any sort of service as you envision only needs one thing - a set of project URLs. It can pull those from Packagist (if you can backtrack how its API works - not hard), crawl git repositories, accept anonymous URL submissions, etc.
well each project usually as a pretty clearly defined domain where they host docs and various other links.
the can always announce their shorter url on their main domain. that being said, i dont think that such URLs need to be short.
Packagist has no issues associating projects with URIs... This sounds a lot like a problem that doesn't exist.
The approach currently is:
1. Define a file to be included in the project's repository.
2. This file either contains the information itself or a url where it can be fetched from.
3. Define a standard representation
>> How do you make sure that a submitted URL really belongs to that project ?
1. The information comes from the project's own repository.
You'd have to create a fake repository and point to a wrong address for no gain whatsoever. That already is a strong deterrent. [1]
2. Any kind of moderation measures are outside of the FIG's scope.
[1] In theory I could fork a project and change the address. Users that use the fork could then be fed false information introducing exploitable weaknesses. But then I could've just changed the code itself. I don't believe this is a relevant scenario.
~John
>> How do you make sure that a submitted URL really belongs to that project ?
1. The information comes from the project's own repository.
You'd have to create a fake repository and point to a wrong address for no gain whatsoever. That already is a strong deterrent. [1]
2. Any kind of moderation measures are outside of the FIG's scope.
On Friday, October 31, 2014 3:43:00 PM UTC+2, Pádraic Brady wrote:
Any sort of service as you envision only needs one thing - a set of project URLs. It can pull those from Packagist (if you can backtrack how its API works - not hard), crawl git repositories, accept anonymous URL submissions, etc.
On Friday, October 31, 2014 3:43:00 PM UTC+2, Pádraic Brady wrote:Any sort of service as you envision only needs one thing - a set of project URLs. It can pull those from Packagist (if you can backtrack how its API works - not hard), crawl git repositories, accept anonymous URL submissions, etc.
More precise to "accept anonymous URL submissions".
It would, of course, fail completely if Packagist data were to become corrupted or untrustworthy.
I’d love to sponsor this as well.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/546055B6.5080806%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
I’ve decided to coordinate. I’ve opened entrance voting.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CALwr1G%3D-b_%3DLZ46f-G93sEAq0bG_wa4bQeyK5J2Vs0pjF_%2BaZw%40mail.gmail.com.
Aloha,
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/8963f1ba-6572-4899-8341-503392b47f6e%40googlegroups.com.
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/45AIj5bPHJ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CALwr1GmD98c-S6YhW_CSnfH1Znb6B2ooUYbwhsfEYy25L2svow%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANamvv1J5N182BL6feNirtQSckv%3D19V1hDrCDt9C56V6G5GBkA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/8963f1ba-6572-4899-8341-503392b47f6e%40googlegroups.com.