kjetilk
commented
6 years ago Dear Mark,
Thank you for reaching out and posting the issue! I think this is a good fit for DOAP, but we need to come up with a concrete design.
I think we should do the two simplest use cases first. Indeed, linking a human-readable security policy seems very straightforward. I think the proposal to add the property doap:security-policy is obviously a good thing.
Then, I also think we should have a very simple way to show the security contact. I'm in a bit of doubt if it would be best (for the consumer, mostly) to have a property that says that a mailbox is expected. Like FOAF has foaf:mbox. So, would be the simplest thing be to have e.g. doap:security-mbox, or like you suggest to have doap:security-contact, and that can be any URI? Perhaps we should both, where the first is for the simplest possible case, where the security contact is just a mailbox, and the latter is used when you want to say something more about it, like attach a key. We could envision something like this (in Turtle syntax):
my:project doap:security-contact <http://example.org/security-team#us> .
<http://example.org/security-team#us> a foaf:Group ;
foaf:mbox <mailto:security@example.org> ;
foaf:name "Example Security Team" ;
wot:hasKey [
a wot:PubKey ;
wot:pubkeyAddress <http://example.org/our-key.asc> ;
wot:hex_id "DEADBEEF"
] . Potentially, you could attach a key to an mbox, like this:
my:project doap:security-mbox <mailto:security@example.org> .
<mailto:security@example.org> wot:hasKey [
a wot:PubKey ;
wot:pubkeyAddress <http://example.org/our-key.asc> ;
wot:hex_id "DEADBEEF"
] . You usually attach the key to the person or group controlling it, not their mailbox, so I don't really like the latter design, but it is a possibility. It makes sense to have a simple mbox property for the simplest cases though. Therefore, I'm inclined to say that we should have both.
And yes, I also figured it may be nice to have a link to SIOC, e.g. doap:security-forum, as SIOC is suited to describe stuff like a mailing list, forums, lists of posts, etc. It could potentially be used for everything from a discussion list on security flaws to security advisories.
BTW, another way to write the doap:security-contact example is to use blank nodes, it can also be written as:
my:project doap:security-contact [
a foaf:Group ;
foaf:mbox <mailto:security@example.org> ;
foaf:name "Example Security Team" ;
wot:hasKey [
a wot:PubKey ;
wot:pubkeyAddress <http://example.org/our-key.asc> ;
wot:hex_id "DEADBEEF"
]
] . 
iamamoose
ewilderj
The Apache Software Foundation has hundreds of separate projects and many are described using DOAP, with various automation using that data. The security team was looking for ways to generate pages showing the security contact for each of the projects and how to get hold of their security updates. While the DOAP files would be the perfect place to hold this data, there isn't suitable fields we can use for this.
Meanwhile other projects, such as securitytxt.org, are trying to build up security-only metadata for projects (and websites) and have spent time looking at what fields are most useful. But it seems to me like DOAP would be a more natural place to describe this. I sent out a ping to Kjetil who recommended opening an issue here to discuss a proposal (and had some useful comments I've incorporated!)
One way of doing this:
Add a security contact
An address that anyone can use to report security issues they found in the described project. Most likely this will be an email address but it's possible it could be any URI
(securitytxt also has fields for the key that can be used for encrypted communication but I think that gets complex really fast (for example some Apache projects require multiple keys with all used, other projects are any used) and I believe these cases would be better handled by pointing to a security policy)
Add a security policy
A link to the projects security policy which describes how they deal with issues.
(securitytxt also has a link for acknowledgements but I believe this is better handled by the projects security policy). Ideally you'd also have a link to a page listing the vulnerabilities themselves, but this might be better handled by the security-policy page too.
or
As an alternative perhaps could this be handled by a doap:security-forum in a similar way to the existing support-forum. I'm not familiar enough with SIOC to see if that would be sufficient to describe all these fields correctly.