Re: About 'qemu-security' mailing list
Hello Dan, Stefan, +-- On Tue, 17 Nov 2020, Daniel P. Berrangé wrote --+ | On Tue, Nov 17, 2020 at 04:19:42PM +, Stefan Hajnoczi wrote: | > Dan and I tried out confidential issues and unfortunately it is | > currently too limited for our workflow. | > | > It is not possible to add non-members to a confidential issue. Members | > need at least the 'Reporter' role to view confidential issues, and then | > they can view all of them (!). | > | > This means there is no way of working on a need-to-know basis. We would | > have to give anyone who ever needs to comment on an issue access to all | > other issues :(. | > | > Dan found this open feature request from 2 years ago: | > https://gitlab.com/gitlab-org/gitlab/-/issues/20252 | > | > For now I think we should stick to email. I think email is best and easiest for all. | > I'm still concerned about the prospect of writing custom mailing list | > software and hosting it somewhere. Can we run an encrypted mailing list | > without developing the software ourselves? | | We certainly should NOT get into the business of writing or hosting | custom solutions ourselves IMHO. Even if someone volunteers to do the | work upfront, that'll inevitably turn into abandonware a few years | hence when the interested party moves onto other things. * I don't know of any list provider which supports encryption. * For custom software, there is this 'schleuder' project -> https://0xacab.org/schleuder/schleuder -> https://schleuder.org/schleuder/docs/concept.html A gpg-enabled mailing list manager with resending-capabilities. * I have not used it or played with it. | I still question whether we genuinely need encrypted mailing lists in | the first place. | | Our of all the security reports QEMU has received how many reporters | actually used GPG to encrypt their reporters, and how often did the | security team actually keep using GPG when triaging and resolving it | thereafter. | | Out of countless security issues I've dealt with across many software | projects for 10 years, there have been less than 5 occassions where | encryption was used with email by a bug reporter notifying me, and out | of those only 1 of them actually justified the use of GPG. | | For projects that did use confidential issues, they still all emailed | notifications in clear text behind the scenes regardless. | | Is it not sufficient to just use a regular mailing list by default, | and continue publish security team pgp email addrs + keys for the | few cases where pgp might be desired. * True, need & usage of encryption is debatable and difficult. * Above points and possible solution of keeping the current handful PGP keys available did come up earlier -> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg05213.html * At this point I think, let's get started with a regular list for now. We can still continue to explore encryption support options. @Stefanha: do we need to file a request ticket to create 'qemu-security' list? Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Re: About 'qemu-security' mailing list
On Tue, Nov 17, 2020 at 04:19:42PM +, Stefan Hajnoczi wrote: > On Tue, Nov 17, 2020 at 02:46:12PM +, Stefan Hajnoczi wrote: > > On Fri, Oct 16, 2020 at 07:47:01PM +0530, P J P wrote: > > > > I have CCed everyone from the Security Process wiki page so they can > > participate in discussing changes to the process. > > > > > * So ie. we need to: > > > > > > 1. Create/setup a regular non-encrypted 'qemu-security' list. > > > > > > 2. Invite representatives from user/downstream communities to subscribe > > > to > > > it. > > > > > > 3. Collect & store their PGP public keys. Also create a key for the > > > list. > > > > > > 4. Write 'encrypt & email' automation tool(s) to provide encryption > > > support. > > > > > > 5. Document and publish above details and list workflow on a page. > > > > > > > > > ...wdyt? > > > > Writing/maintaining automation tools will take time so I suggest going > > with confidential GitLab Issues instead: > > https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html > > > > If you would like to test GitLab Issues, please post your username and > > you will be given the "Reporter" role so you can view confidential > > issues. > > > > I have created a confidential issue here (you'll get 404 if you don't > > have permissions to view it): > > https://gitlab.com/qemu-project/qemu/-/issues/2 > > > > The intention is to migrate QEMU's bug tracker from Launchpad to GitLab > > so this will unify reporting regular bugs and security bugs. It also > > uses encryption all the time instead of relying on users explicitly > > encrypting emails. > > Dan and I tried out confidential issues and unfortunately it is > currently too limited for our workflow. > > It is not possible to add non-members to a confidential issue. Members > need at least the 'Reporter' role to view confidential issues, and then > they can view all of them (!). > > This means there is no way of working on a need-to-know basis. We would > have to give anyone who ever needs to comment on an issue access to all > other issues :(. > > Dan found this open feature request from 2 years ago: > https://gitlab.com/gitlab-org/gitlab/-/issues/20252 > > For now I think we should stick to email. I'm still concerned about the > prospect of writing custom mailing list software and hosting it > somewhere. Can we run an encrypted mailing list without developing the > software ourselves? We certainly should NOT get into the business of writing or hosting custom solutions ourselves IMHO. Even if someone volunteers to do the work upfront, that'll inevitably turn into abandonware a few years hence when the interested party moves onto other things. I still question whether we genuinely need encrypted mailing lists in the first place. Our of all the security reports QEMU has received how many reporters actually used GPG to encrypt their reporters, and how often did the security team actually keep using GPG when triaging and resolving it thereafter. Out of countless security issues I've dealt with across many software projects for 10 years, there have been less than 5 occassions where encryption was used with email by a bug reporter notifying me, and out of those only 1 of them actually justified the use of GPG. For projects that did use confidential issues, they still all emailed notifications in clear text behind the scenes regardless. Is it not sufficient to just use a regular mailing list by default, and continue publish security team pgp email addrs + keys for the few cases where pgp might be desired. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: About 'qemu-security' mailing list
On Tue, Nov 17, 2020 at 02:46:12PM +, Stefan Hajnoczi wrote: > On Fri, Oct 16, 2020 at 07:47:01PM +0530, P J P wrote: > > I have CCed everyone from the Security Process wiki page so they can > participate in discussing changes to the process. > > > * So ie. we need to: > > > > 1. Create/setup a regular non-encrypted 'qemu-security' list. > > > > 2. Invite representatives from user/downstream communities to subscribe > > to > > it. > > > > 3. Collect & store their PGP public keys. Also create a key for the list. > > > > 4. Write 'encrypt & email' automation tool(s) to provide encryption > > support. > > > > 5. Document and publish above details and list workflow on a page. > > > > > > ...wdyt? > > Writing/maintaining automation tools will take time so I suggest going > with confidential GitLab Issues instead: > https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html > > If you would like to test GitLab Issues, please post your username and > you will be given the "Reporter" role so you can view confidential > issues. > > I have created a confidential issue here (you'll get 404 if you don't > have permissions to view it): > https://gitlab.com/qemu-project/qemu/-/issues/2 > > The intention is to migrate QEMU's bug tracker from Launchpad to GitLab > so this will unify reporting regular bugs and security bugs. It also > uses encryption all the time instead of relying on users explicitly > encrypting emails. Dan and I tried out confidential issues and unfortunately it is currently too limited for our workflow. It is not possible to add non-members to a confidential issue. Members need at least the 'Reporter' role to view confidential issues, and then they can view all of them (!). This means there is no way of working on a need-to-know basis. We would have to give anyone who ever needs to comment on an issue access to all other issues :(. Dan found this open feature request from 2 years ago: https://gitlab.com/gitlab-org/gitlab/-/issues/20252 For now I think we should stick to email. I'm still concerned about the prospect of writing custom mailing list software and hosting it somewhere. Can we run an encrypted mailing list without developing the software ourselves? Stefan signature.asc Description: PGP signature
Re: About 'qemu-security' mailing list
On Fri, Oct 16, 2020 at 07:47:01PM +0530, P J P wrote: I have CCed everyone from the Security Process wiki page so they can participate in discussing changes to the process. > * So ie. we need to: > > 1. Create/setup a regular non-encrypted 'qemu-security' list. > > 2. Invite representatives from user/downstream communities to subscribe to > it. > > 3. Collect & store their PGP public keys. Also create a key for the list. > > 4. Write 'encrypt & email' automation tool(s) to provide encryption support. > > 5. Document and publish above details and list workflow on a page. > > > ...wdyt? Writing/maintaining automation tools will take time so I suggest going with confidential GitLab Issues instead: https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html If you would like to test GitLab Issues, please post your username and you will be given the "Reporter" role so you can view confidential issues. I have created a confidential issue here (you'll get 404 if you don't have permissions to view it): https://gitlab.com/qemu-project/qemu/-/issues/2 The intention is to migrate QEMU's bug tracker from Launchpad to GitLab so this will unify reporting regular bugs and security bugs. It also uses encryption all the time instead of relying on users explicitly encrypting emails. Stefan signature.asc Description: PGP signature
Re: About 'qemu-security' mailing list
+-- On Tue, 20 Oct 2020, P J P wrote --+ | +-- On Fri, 16 Oct 2020, P J P wrote --+ | | * So ie. we need to: | | | | 1. Create/setup a regular non-encrypted 'qemu-security' list. | | | | 2. Invite representatives from user/downstream communities to subscribe to | | it. | | | | 3. Collect & store their PGP public keys. Also create a key for the list. | | | | 4. Write 'encrypt & email' automation tool(s) to provide encryption support. | | | | 5. Document and publish above details and list workflow on a page. | | | | ...wdyt? | Ping...! -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Re: About 'qemu-security' mailing list
+-- On Fri, 16 Oct 2020, P J P wrote --+ | * So ie. we need to: | | 1. Create/setup a regular non-encrypted 'qemu-security' list. | | 2. Invite representatives from user/downstream communities to subscribe to | it. | | 3. Collect & store their PGP public keys. Also create a key for the list. | | 4. Write 'encrypt & email' automation tool(s) to provide encryption support. | | 5. Document and publish above details and list workflow on a page. | | ...wdyt? Ping..! (just checking; probably folks are buys with KVMForum I guess) -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Re: About 'qemu-security' mailing list
Hello Darren, all +-- On Thu, 1 Oct 2020, Darren Kenny wrote --+ | On Thursday, 2020-10-01 at 16:05:58 +0530, P J P wrote: | > - A list member triaging such issue, would have to select their individual | > keys for each reply. | | Maybe, honestly not had to deal with it personally. "Ideally, encrypt all of your messages to their (possibly multiple) recipients. This means that you need not only the list's public key, but also keys for the reporter and for anyone else CC'ed. You may exercise your best effort to obtain such keys (from keyservers, by asking in the thread in plaintext without quoting any sensitive content, etc.), or failing that you may fallback to plaintext, in which case you should refrain from quoting (and adding) non-essential sensitive content. For example, if you merely want the reporter to agree to or specify a public disclosure date, then you may send a plaintext message back to them with this request and nothing else (most importantly, do not quote their original report)." -> https://oss-security.openwall.org/wiki/mailing-lists/distros * Found above text for encrypted email workflow to communicate with non-member reporters. +-- On Thu, 1 Oct 2020, P J P wrote --+ | Encrypted list, open to receive non-encrypted reports seems okay. Will have | to check how to set it up and its workflow. * I reached out to '@solardiz' to check if the back end scripts/tools which power automatic encryption on '-distros' list are available as open source tools. Unfortunately not. * As his suggestions/inputs for a list, he said: >On Friday, 9 October, 2020, 12:15:37 am IST, Solar Designer wrote: > > my biggest concern is that issues discussed there or reproducers for them > might stay unpublished for very long, and would be a lucrative target. > I think a more important than encryption property of the distros list is > that we impose a maximum embargo time, and have requirements on > publication of exploits too if those were provided. > * So ie. we need to: 1. Create/setup a regular non-encrypted 'qemu-security' list. 2. Invite representatives from user/downstream communities to subscribe to it. 3. Collect & store their PGP public keys. Also create a key for the list. 4. Write 'encrypt & email' automation tool(s) to provide encryption support. 5. Document and publish above details and list workflow on a page. ...wdyt? Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Re: About 'qemu-security' mailing list
+-- On Thu, 1 Oct 2020, Darren Kenny wrote --+ | The storage of reproducers would indeed be good to have in something | like Gitlab - but that'd require someone to extract it and store it, but | under what naming would be another issue... But really that's behind the | scenes. Yes. | > Maybe we could start with a moderated list and improvise as we go forward? | | I really think that encryption of the details of a vulnerability is | important, if somehow it gets intercepted - which is not that difficult with | e-mail - then there is the potential for a malicious party to exploit it | before a fix is available to distros, and deployed. Encrypted list, open to receive non-encrypted reports seems okay. Will have to check how to set it up and its workflow. | Something that has happened since the Intel Spectre/Meltdown vulnerabilities | were initially brought to light is more communication between security teams | in various orgs. To do this those discussions have started being done on | Keybase, which provides secure chats as well as secured Git repos. | | Has anything like that being considered as the point for subsequent | discussions on issues post the initial disclosure? That has not come up for QEMU issues yet. Maybe we could consider it in future if required. +-- On Thu, 1 Oct 2020, Konrad Rzeszutek Wilk wrote --+ | The problem with Keybase was how to review patches. Now if they had a | encrypted mailing list as part of their Git repos that would be awesome. | (Trying to find a "Feature request" but not having much luck :-() True. Email + PGP/GPG has been around for so many years, yet there is no seamless combination of the two. :( Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Re: About 'qemu-security' mailing list
. monster snip.. > > Maybe we could start with a moderated list and improvise as we go forward? > > I really think that encryption of the details of a vulnerability is > important, if somehow it gets intercepted - which is not that difficult > with e-mail - then there is the potential for a malicious party to > exploit it before a fix is available to distros, and deployed. .. I found out yesterday that most of the emails around the world are using TLS which does remove the interception part. The attack is then to get on say Prasad's box .. and if you do that it really does not matter if you use encryption or not. > > Something that has happened since the Intel Spectre/Meltdown > vulnerabilities were initially brought to light is more communication > between security teams in various orgs. To do this those discussions > have started being done on Keybase, which provides secure chats as well > as secured Git repos. > > Has anything like that being considered as the point for subsequent > discussions on issues post the initial disclosure? The problem with Keybase was how to review patches. Now if they had a encrypted mailing list as part of their Git repos that would be awesome. (Trying to find a "Feature request" but not having much luck :-()
Re: About 'qemu-security' mailing list
On Thursday, 2020-10-01 at 16:05:58 +0530, P J P wrote: > Hello Darren, > > +-- On Wed, 30 Sep 2020, Darren Kenny wrote --+ > | While that is true, some aliases have managed to do something here by > having > | a single key for the alias, and behind the scenes that re-encrypts the > | e-mail for each member of that alias (trying to avoid the 'list' term a > | little here) > | > | An example of this is the 'distro's list, e.g.: > | - https://oss-security.openwall.org/wiki/mailing-lists/distros > > * Yes, true. But it accepts non-encrypted reports too IIUC. I believe so. I wonder, in the case of non-encrypted reports, it would be better to suggest that in that case, it would only be an initial contact, no significant details. After that some discussion could be done on reproducers, etc on a more secure list. > > * I'm not sure how is the 'behind the scenes re-encryption' workflow for > non-member reporters. > > - Ex. say 2-3 non-member reporter(s) send an encrypted report with their > public keys. > AFAIK the original message needs to be encrypted with a specific key, which is on the website above - so all reporters would be using that. > - A list member triaging such issue, would have to select their individual > keys for each reply. Maybe, honestly not had to deal with it personally. > > > | If you're looking to announce before a security issue is fixed, it may just > | be better to keep it to the qemu-security members, which should try to > | include at least 1, if not more, members from interested distros. > > * No, I didn't mean an '-announce' list for non-security members. I was more > wondering about how to handle reproducers and other artefacts sent to the > list. The storage of reproducers would indeed be good to have in something like Gitlab - but that'd require someone to extract it and store it, but under what naming would be another issue... But really that's behind the scenes. > > * Proposed 'qemu-security' list is meant to have representatives from > downstream QEMU user communities. Excellent, that would be good. > > > | I know from past kernel security issues, it is still important to a distro > | to be able to reproduce any issues if a PoC is provided. > > * Yes, that's true. It should be okay in that case to keep the reproducers > and > such artefacts on the list then. > > ... > > | I would agree that Gitlab may be better here, if it would work - Gitlab > | can certainly be configured to restrict access to specific projects, but > | I'm not sure how that would play into logging an issue if you can't even > | see the project in question as a non-member of the security team. > > * True. Reporters may need to open/create GitLab account to report issues. Hmm, it's here that I think it becomes difficult for everyone to log an issue, even with an account, you may not be able to log an issue on a project that is otherwise secured. > > To summarise: > = > - Bugzilla or GitLab issues would entail reporters create an account there > to report issues. > > - On a moderated 'qemu-security' list, even a non-member shall be able to > report issues via email. > > - Many voices have said 'Yes' for a moderated 'qemu-security' list. > > - Whether to have an encrypted list or otherwise, is an open question. > > + Encrypted list(ex. -distros) is possible. But it accepts non-encrypted > mails too IIUC. > > + Mandatory encryption would entail reporters create/share their keys. > It may become tricky, if reporters are non-members. > > - It should be okay to keep reproducers etc. artefacts on the list..? > List archives shall not be publicly accessible. > > > Maybe we could start with a moderated list and improvise as we go forward? I really think that encryption of the details of a vulnerability is important, if somehow it gets intercepted - which is not that difficult with e-mail - then there is the potential for a malicious party to exploit it before a fix is available to distros, and deployed. Something that has happened since the Intel Spectre/Meltdown vulnerabilities were initially brought to light is more communication between security teams in various orgs. To do this those discussions have started being done on Keybase, which provides secure chats as well as secured Git repos. Has anything like that being considered as the point for subsequent discussions on issues post the initial disclosure? Thanks, Darren.
Re: About 'qemu-security' mailing list
Hello Darren, +-- On Wed, 30 Sep 2020, Darren Kenny wrote --+ | While that is true, some aliases have managed to do something here by having | a single key for the alias, and behind the scenes that re-encrypts the | e-mail for each member of that alias (trying to avoid the 'list' term a | little here) | | An example of this is the 'distro's list, e.g.: | - https://oss-security.openwall.org/wiki/mailing-lists/distros * Yes, true. But it accepts non-encrypted reports too IIUC. * I'm not sure how is the 'behind the scenes re-encryption' workflow for non-member reporters. - Ex. say 2-3 non-member reporter(s) send an encrypted report with their public keys. - A list member triaging such issue, would have to select their individual keys for each reply. | If you're looking to announce before a security issue is fixed, it may just | be better to keep it to the qemu-security members, which should try to | include at least 1, if not more, members from interested distros. * No, I didn't mean an '-announce' list for non-security members. I was more wondering about how to handle reproducers and other artefacts sent to the list. * Proposed 'qemu-security' list is meant to have representatives from downstream QEMU user communities. | I know from past kernel security issues, it is still important to a distro | to be able to reproduce any issues if a PoC is provided. * Yes, that's true. It should be okay in that case to keep the reproducers and such artefacts on the list then. | There are some existing mechanisms for announcing security issues once | found, e.g. oss-security: | | - https://oss-security.openwall.org/wiki/mailing-lists/oss-security | | A lot of distros have people on this list already monitoring it and many OSS | projects do send announcements of CVEs and security issues to this, once | resolved and an embargo period has expired - including Qemu, as I'm sure | that you know, given I've seen postings from you (Prasad) there. | | Why would this not be enough for that? * Yes, that is a fine, working means of public announcements. We currently use the same. | > * These representatives then decide if an issue can be readily disclosed and | > discussed on the public 'qemu-devel' list OR needs to go through an embargo | > process. | | These are all very important points - and the need for an embargo period | can be vital where Qemu/KVM is being widely deployed in a company. ... | | * Between LaunchPad and GitLab, I think GitLab is preferable. | I would agree that Gitlab may be better here, if it would work - Gitlab | can certainly be configured to restrict access to specific projects, but | I'm not sure how that would play into logging an issue if you can't even | see the project in question as a non-member of the security team. * True. Reporters may need to open/create GitLab account to report issues. To summarise: = - Bugzilla or GitLab issues would entail reporters create an account there to report issues. - On a moderated 'qemu-security' list, even a non-member shall be able to report issues via email. - Many voices have said 'Yes' for a moderated 'qemu-security' list. - Whether to have an encrypted list or otherwise, is an open question. + Encrypted list(ex. -distros) is possible. But it accepts non-encrypted mails too IIUC. + Mandatory encryption would entail reporters create/share their keys. It may become tricky, if reporters are non-members. - It should be okay to keep reproducers etc. artefacts on the list..? List archives shall not be publicly accessible. Maybe we could start with a moderated list and improvise as we go forward? Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Re: About 'qemu-security' mailing list
Hi Prasad, Just my 2c as someone working on a downstream distro with Qemu... On Friday, 2020-09-18 at 12:32:23 +0530, P J P wrote: > Hello all, > > +-- On Wed, 16 Sep 2020, Stefan Hajnoczi wrote --+ > | I'm surprised the lack of encryption doesn't bother you. The security bug > | reporting process should be confidential to prevent disclosure of 0-days. > > * I think it'll work only if all issue reports are encrypted. Under current > process, we've our GPG keys published, yet majority of the issue reports > are > unencrypted. CVEs are of more interest/incentive. > > * Encrypted email workflow is also not as seamless as unencrypted. > While that is true, some aliases have managed to do something here by having a single key for the alias, and behind the scenes that re-encrypts the e-mail for each member of that alias (trying to avoid the 'list' term a little here) An example of this is the 'distro's list, e.g.: - https://oss-security.openwall.org/wiki/mailing-lists/distros > > | Triaging and fixing are different things. Where is the bottleneck, triaging > | or fixing? > > * Issue triaging/analysis is lesser time; Patches may take longer, so fixing. > > * But having mailing-list isn't going to affect/address either. > > > | Do downstream maintainers want to know about potential security bug reports > | that have not been triaged yet? > | > | Maybe there should there be a pre-announce list for bugs that have been > | triaged? That saves downstream from being spammed with confidential info > | that they probably can't use. > > * I was thinking about that, an '-announce' list could be better. Because > issue reports may come with reproducers (code/scripts/packet dump). And > sharing such reproducers with wide-rs recipients seems risky, not right. > > * Such reproducers shall stay in the list archives forever. It may have some > legal IP related concerns. I'm not sure. I believe there was some resistance in the Linux kernel security space of having things like a pre-announce message of a security issue that has come in but is not fixed yet... If you're looking to announce before a security issue is fixed, it may just be better to keep it to the qemu-security members, which should try to include at least 1, if not more, members from interested distros. I know from past kernel security issues, it is still important to a distro to be able to reproduce any issues if a PoC is provided. There are some existing mechanisms for announcing security issues once found, e.g. oss-security: - https://oss-security.openwall.org/wiki/mailing-lists/oss-security A lot of distros have people on this list already monitoring it and many OSS projects do send announcements of CVEs and security issues to this, once resolved and an embargo period has expired - including Qemu, as I'm sure that you know, given I've seen postings from you (Prasad) there. Why would this not be enough for that? > | I don't think a broadcast model works well for assigning responsibility. If > | maintainers constantly receive security-related emails (most of which don't > | affect them), they will ignore them. This is what happens with broadcast CI > | and fuzzing results. > | > | Instead someone should assign security bug reports to relevant maintainers. > | > | Another option is to let reporters directly contact the maintainers (e.g. > | QEMU's MAINTAINERS file), but this is hard to get right and if a maintainer > | is on vacation the report may go unnoticed. > > * True, agree. > > > | Anyway, it's unclear to me what the motivation for creating a list and > | changing the process is. Please share your goals and reasoning in more > | detail. > > * Primary motivation is to address the concern that current process limits > community participation. > > * Representatives from downstream QEMU user communities shall be notified > about security issues as and when they come in. > > * These representatives then decide if an issue can be readily disclosed and > discussed on the public 'qemu-devel' list OR needs to go through an embargo > process. These are all very important points - and the need for an embargo period can be vital where Qemu/KVM is being widely deployed in a company. > > > | I think it's worth investigating whether GitLab Issues can be configured in > | a secure-enough way for security bug reporting. That way HTTPS is used and > | only GitLab stores the confidential information (this isn't end-to-end > | encryption but seems better than unencrypted SMTP and plaintext emails > | copied across machines). > > +-- On Wed, 16 Sep 2020, Peter Maydell wrote --+ > | Given that we currently use launchpad for bugs we should also look at > | whether launchpad's "private security" bug classification would be useful > | for us (currently such bug reports effectively go to /dev/null but this can > | be fixed). > > > * Bug trackers would entail that reporters must have an account there. They > may cre
Re: About 'qemu-security' mailing list
+-- On Fri, 18 Sep 2020, P J P wrote --+ | +-- On Wed, 16 Sep 2020, Stefan Hajnoczi wrote --+ | | Do downstream maintainers want to know about potential security bug reports | | that have not been triaged yet? | | | | Maybe there should there be a pre-announce list for bugs that have been | | triaged? That saves downstream from being spammed with confidential info | | that they probably can't use. | | * I was thinking about that, an '-announce' list could be better. Because | issue reports may come with reproducers (code/scripts/packet dump). And | sharing such reproducers with wide-rs recipients seems risky, not right. | | * Such reproducers shall stay in the list archives forever. It may have some | legal IP related concerns. I'm not sure. ... | | | Anyway, it's unclear to me what the motivation for creating a list and | | changing the process is. Please share your goals and reasoning in more | | detail. | | * Primary motivation is to address the concern that current process limits | community participation. | | * Representatives from downstream QEMU user communities shall be notified | about security issues as and when they come in. | | * These representatives then decide if an issue can be readily disclosed and | discussed on the public 'qemu-devel' list OR needs to go through an embargo | process. | | | | I think it's worth investigating whether GitLab Issues can be configured in | | a secure-enough way for security bug reporting. That way HTTPS is used and | | only GitLab stores the confidential information (this isn't end-to-end | | encryption but seems better than unencrypted SMTP and plaintext emails | | copied across machines). | | +-- On Wed, 16 Sep 2020, Peter Maydell wrote --+ | | Given that we currently use launchpad for bugs we should also look at | | whether launchpad's "private security" bug classification would be useful | | for us (currently such bug reports effectively go to /dev/null but this can | | be fixed). | | | * Bug trackers would entail that reporters must have an account there. They | may create account also, but if/when they become inactive, they'll continue | to receive emails or have access to security bugs. | | A mailing list works more on invite-only basis that way. | | * Bug trackers may also face the current limitation of community participants | not knowing about the issues as and when they come in. | | * So bug trackers need a way to send an email to a -announce/-security list, | sans the reproducer code/scripts/packet dump etc. information. | | * Between LaunchPad and GitLab, I think GitLab is preferable. Ping...!? -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Re: About 'qemu-security' mailing list
Hello Alex, +-- On Fri, 11 Sep 2020, Alexander Bulekov wrote --+ | * I'm guessing this will be a closed list with some application/vetting |procedure for the participants? (Maybe this is what you mean by |"moderated" ?) Yes. | * Will secalert still be subscribed (for managing CVE ID assignments)? Yes. | * How will the communication be encrypted? | * Assuming PGP will be gone, Few contacts with PGP keys could be made available for encrypted communication. | will it be possible to make the "This bug is a security vulnerability" | button work on Launchpad? Not sure, will have to check about it. Thank you. (Sorry, I missed to reply here earlier.) -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Re: About 'qemu-security' mailing list
Hello all, +-- On Wed, 16 Sep 2020, Stefan Hajnoczi wrote --+ | I'm surprised the lack of encryption doesn't bother you. The security bug | reporting process should be confidential to prevent disclosure of 0-days. * I think it'll work only if all issue reports are encrypted. Under current process, we've our GPG keys published, yet majority of the issue reports are unencrypted. CVEs are of more interest/incentive. * Encrypted email workflow is also not as seamless as unencrypted. | Triaging and fixing are different things. Where is the bottleneck, triaging | or fixing? * Issue triaging/analysis is lesser time; Patches may take longer, so fixing. * But having mailing-list isn't going to affect/address either. | Do downstream maintainers want to know about potential security bug reports | that have not been triaged yet? | | Maybe there should there be a pre-announce list for bugs that have been | triaged? That saves downstream from being spammed with confidential info | that they probably can't use. * I was thinking about that, an '-announce' list could be better. Because issue reports may come with reproducers (code/scripts/packet dump). And sharing such reproducers with wide-rs recipients seems risky, not right. * Such reproducers shall stay in the list archives forever. It may have some legal IP related concerns. I'm not sure. | I don't think a broadcast model works well for assigning responsibility. If | maintainers constantly receive security-related emails (most of which don't | affect them), they will ignore them. This is what happens with broadcast CI | and fuzzing results. | | Instead someone should assign security bug reports to relevant maintainers. | | Another option is to let reporters directly contact the maintainers (e.g. | QEMU's MAINTAINERS file), but this is hard to get right and if a maintainer | is on vacation the report may go unnoticed. * True, agree. | Anyway, it's unclear to me what the motivation for creating a list and | changing the process is. Please share your goals and reasoning in more | detail. * Primary motivation is to address the concern that current process limits community participation. * Representatives from downstream QEMU user communities shall be notified about security issues as and when they come in. * These representatives then decide if an issue can be readily disclosed and discussed on the public 'qemu-devel' list OR needs to go through an embargo process. | I think it's worth investigating whether GitLab Issues can be configured in | a secure-enough way for security bug reporting. That way HTTPS is used and | only GitLab stores the confidential information (this isn't end-to-end | encryption but seems better than unencrypted SMTP and plaintext emails | copied across machines). +-- On Wed, 16 Sep 2020, Peter Maydell wrote --+ | Given that we currently use launchpad for bugs we should also look at | whether launchpad's "private security" bug classification would be useful | for us (currently such bug reports effectively go to /dev/null but this can | be fixed). * Bug trackers would entail that reporters must have an account there. They may create account also, but if/when they become inactive, they'll continue to receive emails or have access to security bugs. A mailing list works more on invite-only basis that way. * Bug trackers may also face the current limitation of community participants not knowing about the issues as and when they come in. * So bug trackers need a way to send an email to a -announce/-security list, sans the reproducer code/scripts/packet dump etc. information. * Between LaunchPad and GitLab, I think GitLab is preferable. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Re: About 'qemu-security' mailing list
On Wed, Sep 16, 2020 at 03:25:45PM +0200, Thomas Huth wrote: > On 16/09/2020 15.06, Daniel P. Berrangé wrote: > > Using a bug tracker has the notable advantage over direct email CC's > > that if the security triage team needs to pull in a domain specific > > expert, that newly added person can still see the full history of > > discussion on the bug. > > > > With individual email CC's, the previous discussions are essentially > > a information blackhole until the security triage team is good enough > > to forward the full discussion history (this essentially never happens > > in IME). Mailing list also has that easy archive access benefit. > > > > Is it possible to setup people to be able to view launchpad private > > bugs, without also making them full admins for the QEMU launchpad > > project ? > > Honestly, I'd rather like use to move to the gitlab bug tracker instead > of extending our use of the launchpad tracker. LP is IMHO a really ugly > bug tracking tool. I assume you mean here moving to use GitLab for *all* bug tracking, not merely security bug tracking ? I don't think it would be sane to split our process across different bug trackers. I have no love for LP, so wouldn't disagree with a move to GitLab, especially if we're intending to expand its usage for other parts of QEMU project infrastructure. If we ever use it as the canonical git repo host, then I'd say using its bug tracker too is pretty much a no-brainer. > > Does launchpad still send clear text email notifications to the > > permitted admins for private bugs ? I recall I used to get clear > > text emails for private bugs in the past for non-QEMU projects. > > IIRC, yes, the email notifications for the private bugs are still send > without encryption. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: About 'qemu-security' mailing list
On 16/09/2020 15.06, Daniel P. Berrangé wrote: > On Wed, Sep 16, 2020 at 01:33:38PM +0100, Peter Maydell wrote: >> On Wed, 16 Sep 2020 at 12:10, Stefan Hajnoczi wrote: >>> I think it's worth investigating whether GitLab Issues can be configured >>> in a secure-enough way for security bug reporting. That way HTTPS is >>> used and only GitLab stores the confidential information (this isn't >>> end-to-end encryption but seems better than unencrypted SMTP and >>> plaintext emails copied across machines). >> >> Given that we currently use launchpad for bugs we should also look >> at whether launchpad's "private security" bug classification would >> be useful for us (currently such bug reports effectively go to /dev/null >> but this can be fixed). I've somehow managed to subscribe myself to our private LP bugs, so I get notified if there is a new one. > Using a bug tracker has the notable advantage over direct email CC's > that if the security triage team needs to pull in a domain specific > expert, that newly added person can still see the full history of > discussion on the bug. > > With individual email CC's, the previous discussions are essentially > a information blackhole until the security triage team is good enough > to forward the full discussion history (this essentially never happens > in IME). Mailing list also has that easy archive access benefit. > > Is it possible to setup people to be able to view launchpad private > bugs, without also making them full admins for the QEMU launchpad > project ? Honestly, I'd rather like use to move to the gitlab bug tracker instead of extending our use of the launchpad tracker. LP is IMHO a really ugly bug tracking tool. > Does launchpad still send clear text email notifications to the > permitted admins for private bugs ? I recall I used to get clear > text emails for private bugs in the past for non-QEMU projects. IIRC, yes, the email notifications for the private bugs are still send without encryption. Thomas
Re: About 'qemu-security' mailing list
On Wed, Sep 16, 2020 at 01:33:38PM +0100, Peter Maydell wrote: > On Wed, 16 Sep 2020 at 12:10, Stefan Hajnoczi wrote: > > I think it's worth investigating whether GitLab Issues can be configured > > in a secure-enough way for security bug reporting. That way HTTPS is > > used and only GitLab stores the confidential information (this isn't > > end-to-end encryption but seems better than unencrypted SMTP and > > plaintext emails copied across machines). > > Given that we currently use launchpad for bugs we should also look > at whether launchpad's "private security" bug classification would > be useful for us (currently such bug reports effectively go to /dev/null > but this can be fixed). Using a bug tracker has the notable advantage over direct email CC's that if the security triage team needs to pull in a domain specific expert, that newly added person can still see the full history of discussion on the bug. With individual email CC's, the previous discussions are essentially a information blackhole until the security triage team is good enough to forward the full discussion history (this essentially never happens in IME). Mailing list also has that easy archive access benefit. Is it possible to setup people to be able to view launchpad private bugs, without also making them full admins for the QEMU launchpad project ? Does launchpad still send clear text email notifications to the permitted admins for private bugs ? I recall I used to get clear text emails for private bugs in the past for non-QEMU projects. This reduces the security benefits of launchpad compared to email, though it is still a clear win in terms of triage process most likely. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: About 'qemu-security' mailing list
On Wed, 16 Sep 2020 at 12:10, Stefan Hajnoczi wrote: > I think it's worth investigating whether GitLab Issues can be configured > in a secure-enough way for security bug reporting. That way HTTPS is > used and only GitLab stores the confidential information (this isn't > end-to-end encryption but seems better than unencrypted SMTP and > plaintext emails copied across machines). Given that we currently use launchpad for bugs we should also look at whether launchpad's "private security" bug classification would be useful for us (currently such bug reports effectively go to /dev/null but this can be fixed). thanks -- PMM
Re: About 'qemu-security' mailing list
On Tue, Sep 15, 2020 at 04:18:47PM +0530, P J P wrote: > +-- On Fri, 11 Sep 2020, Peter Maydell wrote --+ > | Way way back, the idea of a qemu-security list was proposed, and it was > | decided against because there wasn't a clear way that people could send > | encrypted mail to the security team if it was just a mailing list. So > that's > | why we have the "handful of individual contacts" approach. Is that still > | something people care about ? > > * So far issue reports have mostly been unencrypted. > > * All issue reports may not need encryption. > > * If someone still wants to send an encrypted report, few contacts with their > GPG keys could be made available, as is available now. I'm surprised the lack of encryption doesn't bother you. The security bug reporting process should be confidential to prevent disclosure of 0-days. I think it's worth investigating whether GitLab Issues can be configured in a secure-enough way for security bug reporting. That way HTTPS is used and only GitLab stores the confidential information (this isn't end-to-end encryption but seems better than unencrypted SMTP and plaintext emails copied across machines). > +-- On Mon, 14 Sep 2020, Stefan Hajnoczi wrote --+ > | On Fri, Sep 11, 2020 at 04:51:49PM +0100, Peter Maydell wrote: > | > want it to be a larger grouping than that and maybe also want to use it > as > | > a mechanism for informing downstream distros etc about QEMU security > | > issues, which is to say you're proposing an overhaul and change to our > | > security process, not merely "we'd like to create a mailing list" ? > | > | Yes, please discuss the reasons for wanting a mailing list: > | > | Is the goal to involve more people in triaging CVEs in a timely manner? > > This will be welcome for fix patches. Triaging and fixing are different things. Where is the bottleneck, triaging or fixing? > | Is the goal to include new people who have recently asked to participate? > > We've not received such request yet. > > | Is the goal to use an easier workflow than manually sending encrypted > | email to a handful of people? > > * Current proposal is more for enabling communities and downstream distros to > know about the issues as and when they are reported. Ie. heads-up mechanism. > > Just to note, we've not received any request for such notifications. Do downstream maintainers want to know about potential security bug reports that have not been triaged yet? Maybe there should there be a pre-announce list for bugs that have been triaged? That saves downstream from being spammed with confidential info that they probably can't use. > * If maintainers are on this list, that could help with the triage and fix > patches. I don't think a broadcast model works well for assigning responsibility. If maintainers constantly receive security-related emails (most of which don't affect them), they will ignore them. This is what happens with broadcast CI and fuzzing results. Instead someone should assign security bug reports to relevant maintainers. Another option is to let reporters directly contact the maintainers (e.g. QEMU's MAINTAINERS file), but this is hard to get right and if a maintainer is on vacation the report may go unnoticed. Anyway, it's unclear to me what the motivation for creating a list and changing the process is. Please share your goals and reasoning in more detail. Stefan signature.asc Description: PGP signature
Re: About 'qemu-security' mailing list
Hello, +-- On Fri, 11 Sep 2020, Peter Maydell wrote --+ | Way way back, the idea of a qemu-security list was proposed, and it was | decided against because there wasn't a clear way that people could send | encrypted mail to the security team if it was just a mailing list. So that's | why we have the "handful of individual contacts" approach. Is that still | something people care about ? * So far issue reports have mostly been unencrypted. * All issue reports may not need encryption. * If someone still wants to send an encrypted report, few contacts with their GPG keys could be made available, as is available now. +-- On Mon, 14 Sep 2020, Stefan Hajnoczi wrote --+ | On Fri, Sep 11, 2020 at 04:51:49PM +0100, Peter Maydell wrote: | > want it to be a larger grouping than that and maybe also want to use it as | > a mechanism for informing downstream distros etc about QEMU security | > issues, which is to say you're proposing an overhaul and change to our | > security process, not merely "we'd like to create a mailing list" ? | | Yes, please discuss the reasons for wanting a mailing list: | | Is the goal to involve more people in triaging CVEs in a timely manner? This will be welcome for fix patches. | Is the goal to include new people who have recently asked to participate? We've not received such request yet. | Is the goal to use an easier workflow than manually sending encrypted | email to a handful of people? * Current proposal is more for enabling communities and downstream distros to know about the issues as and when they are reported. Ie. heads-up mechanism. Just to note, we've not received any request for such notifications. * If maintainers are on this list, that could help with the triage and fix patches. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Re: About 'qemu-security' mailing list
On Mon, Sep 14, 2020 at 09:38:07AM +0200, Philippe Mathieu-Daudé wrote: > I don't think so, as I took care to encrypt a bug report and > received the reply unencrypted =) Not sure this is the default > although, as this was my unique experience following the security > process. Hopefully a one-time mistake. Confidentiality is necessary for the disclosure of security bugs, otherwise users are put at risk. Stefan signature.asc Description: PGP signature
Re: About 'qemu-security' mailing list
On Fri, Sep 11, 2020 at 04:51:49PM +0100, Peter Maydell wrote: > It sounds like you > want it to be a larger grouping than that and maybe also > want to use it as a mechanism for informing downstream distros > etc about QEMU security issues, which is to say you're > proposing an overhaul and change to our security process, > not merely "we'd like to create a mailing list" ? Yes, please discuss the reasons for wanting a mailing list: Is the goal to involve more people in triaging CVEs in a timely manner? Is the goal to include new people who have recently asked to participate? Is the goal to use an easier workflow than manually sending encrypted email to a handful of people? etc Stefan signature.asc Description: PGP signature
Re: About 'qemu-security' mailing list
On Mon, 14 Sep 2020 at 09:55, Daniel P. Berrangé wrote: > Do we think the current QEMU security process is working well for the > community as a whole in terms of our downstream consumers learning about > security flaws in an appropriate timeframe and manner ? That sounds like a question we should be asking our distro contacts, not guessing at amongst ourselves :-) Personally, my view is that our current security process is absolutely useless for anybody who isn't either (a) a distro (b) using their distro's packaged QEMU (c) big enough to effectively be acting as their own distro by tracking CVE announcements and applying patches by hand -- because we don't produce timely new upstream releases with security fixes. So unless we want to change that, I think the key question is "does this process work for the distros?", and I'm happy if we make adjustments to fix whatever their problems with it might be. thanks -- PMM
Re: About 'qemu-security' mailing list
On Fri, Sep 11, 2020 at 04:51:49PM +0100, Peter Maydell wrote: > On Fri, 11 Sep 2020 at 15:22, P J P wrote: > > Proposal: (to address above limitations) > > = > > > > * We set up a new 'qemu-security' mailing list. > > > > * QEMU security issues are reported to this new list only. > > > > * Representatives from various communities subscribe to this list. (List > > maybe > >moderated in the beginning.) > > > > * As QEMU issues come in, participants on the 'qemu-security' list shall > >discuss and decide about how to triage them further. > > Way way back, the idea of a qemu-security list was proposed, and > it was decided against because there wasn't a clear way that > people could send encrypted mail to the security team if it > was just a mailing list. So that's why we have the "handful > of individual contacts" approach. Is that still something people > care about ? > > My question is, who decides who's on the qemu-security list? > Is this just "it's the same handful of contacts, but they > have a mailing list for convenience" ? It sounds like you > want it to be a larger grouping than that and maybe also > want to use it as a mechanism for informing downstream distros > etc about QEMU security issues, which is to say you're > proposing an overhaul and change to our security process, > not merely "we'd like to create a mailing list" ? Yes, that is a reasonable description. Do we think the current QEMU security process is working well for the community as a whole in terms of our downstream consumers learning about security flaws in an appropriate timeframe and manner ? Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: About 'qemu-security' mailing list
On 9/11/20 5:51 PM, Peter Maydell wrote: > On Fri, 11 Sep 2020 at 15:22, P J P wrote: >> Proposal: (to address above limitations) >> = >> >> * We set up a new 'qemu-security' mailing list. >> >> * QEMU security issues are reported to this new list only. >> >> * Representatives from various communities subscribe to this list. (List >> maybe >>moderated in the beginning.) >> >> * As QEMU issues come in, participants on the 'qemu-security' list shall >>discuss and decide about how to triage them further. > > Way way back, the idea of a qemu-security list was proposed, and > it was decided against because there wasn't a clear way that > people could send encrypted mail to the security team if it > was just a mailing list. So that's why we have the "handful > of individual contacts" approach. Is that still something people > care about ? I don't think so, as I took care to encrypt a bug report and received the reply unencrypted =) Not sure this is the default although, as this was my unique experience following the security process.
Re: About 'qemu-security' mailing list
And I forgot to mention that I think it is a great idea :) . Over the past couple months, I reported a few dozen bugs on launchpad. Even though many of them are memory-corruptions and might fall under the "security-bug" label, they could be fixed faster simply because the reports can reach the maintainer, without a manual triage process. With more eyes available, it could be possible to report fuzzing bugs, while sticking to the security process. It would be especially useful as we are ramping up automated fuzzing on google's oss-fuzz and thinking about how to handle those reports. -Alex On 200911 1140, Alexander Bulekov wrote: > Hi Prasad, > A couple questions: > * I'm guessing this will be a closed list with some application/vetting >procedure for the participants? (Maybe this is what you mean by >"moderated" ?) > * How will the communication be encrypted? > * Will secalert still be subscribed (for managing CVE ID assignments)? > * Assuming PGP will be gone, will it be possible to make the "This bug >is a security vulnerability" button work on Launchpad? > Thanks! > -Alex > > On 200911 1950, P J P wrote: > > Hello all, > > > > Recently while conversing with DanPB this point came up > > > >-> https://www.qemu.org/contribute/security-process/ > > > > * Currently QEMU security team is a handful of individual contacts which > > restricts community participation in dealing with these issues. > > > > * The Onus also lies with the individuals to inform the community about QEMU > > security issues, as they come in. > > > > > > Proposal: (to address above limitations) > > = > > > > * We set up a new 'qemu-security' mailing list. > > > > * QEMU security issues are reported to this new list only. > > > > * Representatives from various communities subscribe to this list. (List > > maybe > > moderated in the beginning.) > > > > * As QEMU issues come in, participants on the 'qemu-security' list shall > > discuss and decide about how to triage them further. > > > > Please kindly let us know your views about it. I'd appreciate if you have > > any suggestions/inputs/comments about the same. > > > > > > Thank you. > > -- > > Prasad J Pandit / Red Hat Product Security Team > > 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D > > > > >
Re: About 'qemu-security' mailing list
On Fri, 11 Sep 2020 at 15:22, P J P wrote: > Proposal: (to address above limitations) > = > > * We set up a new 'qemu-security' mailing list. > > * QEMU security issues are reported to this new list only. > > * Representatives from various communities subscribe to this list. (List maybe >moderated in the beginning.) > > * As QEMU issues come in, participants on the 'qemu-security' list shall >discuss and decide about how to triage them further. Way way back, the idea of a qemu-security list was proposed, and it was decided against because there wasn't a clear way that people could send encrypted mail to the security team if it was just a mailing list. So that's why we have the "handful of individual contacts" approach. Is that still something people care about ? My question is, who decides who's on the qemu-security list? Is this just "it's the same handful of contacts, but they have a mailing list for convenience" ? It sounds like you want it to be a larger grouping than that and maybe also want to use it as a mechanism for informing downstream distros etc about QEMU security issues, which is to say you're proposing an overhaul and change to our security process, not merely "we'd like to create a mailing list" ? thanks -- PMM
Re: About 'qemu-security' mailing list
On Fri, Sep 11, 2020 at 07:50:24PM +0530, P J P wrote: > Hello all, > > Recently while conversing with DanPB this point came up > >-> https://www.qemu.org/contribute/security-process/ > > * Currently QEMU security team is a handful of individual contacts which > restricts community participation in dealing with these issues. > > * The Onus also lies with the individuals to inform the community about QEMU > security issues, as they come in. > > > Proposal: (to address above limitations) > = > > * We set up a new 'qemu-security' mailing list. > > * QEMU security issues are reported to this new list only. > > * Representatives from various communities subscribe to this list. (List maybe > moderated in the beginning.) For libvirt we have the list membership targetted as being nominated security representatives of any downstream distributor of libvirt. ie essentially the security people from various OS vendors. Other members can be considered on a case by case basis if they want to make their case. FWIW, we have the libvirt-security list moderated at all times, and manually approve mails from non-members in order to prevent it being a spam trap. Manual moderation is not too much of a burden assuming the rate of CVEs isn't huge ! > * As QEMU issues come in, participants on the 'qemu-security' list shall > discuss and decide about how to triage them further. For libvirt-security, members are required to respect the project's declared embargo policy. This sets as a 2 week maximum by default, anything beyond 2 weeks has to be explicitly requested as appropriate and not have objection from members of the list. QEMU doesn't set any explicit default embargo period right now just saying it is via mutual agreement: https://www.qemu.org/contribute/security-process/ this might want to be clarified to set a default expectation, because with a list of members you won't want to wait for everyone to explicitly approve a date. You want people to know what to expect as a default upfront, and only have the discussions in cases which need more time. I'm not saying QEMU has to be 2 weeks - perhaps just look at a sample of the past year's CVEs in QEMU and use them as a guide for a reasonable default period to handle or publish the issues. > Please kindly let us know your views about it. I'd appreciate if you have > any suggestions/inputs/comments about the same. I'm in favour of this, since this is what we have done for libvirt upstream security response handling, and it has been a clear improvement on our previous process involving CC'ing individual developers. It makes the security response process more of a level playing field for all downstreams QEMU distributors. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: About 'qemu-security' mailing list
Hi Prasad, A couple questions: * I'm guessing this will be a closed list with some application/vetting procedure for the participants? (Maybe this is what you mean by "moderated" ?) * How will the communication be encrypted? * Will secalert still be subscribed (for managing CVE ID assignments)? * Assuming PGP will be gone, will it be possible to make the "This bug is a security vulnerability" button work on Launchpad? Thanks! -Alex On 200911 1950, P J P wrote: > Hello all, > > Recently while conversing with DanPB this point came up > >-> https://www.qemu.org/contribute/security-process/ > > * Currently QEMU security team is a handful of individual contacts which > restricts community participation in dealing with these issues. > > * The Onus also lies with the individuals to inform the community about QEMU > security issues, as they come in. > > > Proposal: (to address above limitations) > = > > * We set up a new 'qemu-security' mailing list. > > * QEMU security issues are reported to this new list only. > > * Representatives from various communities subscribe to this list. (List maybe > moderated in the beginning.) > > * As QEMU issues come in, participants on the 'qemu-security' list shall > discuss and decide about how to triage them further. > > Please kindly let us know your views about it. I'd appreciate if you have > any suggestions/inputs/comments about the same. > > > Thank you. > -- > Prasad J Pandit / Red Hat Product Security Team > 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D > >
Re: About 'qemu-security' mailing list
P J P 于2020年9月11日周五 下午10:21写道: > >Hello all, > > Recently while conversing with DanPB this point came up > > -> https://www.qemu.org/contribute/security-process/ > > * Currently QEMU security team is a handful of individual contacts which >restricts community participation in dealing with these issues. > > * The Onus also lies with the individuals to inform the community about QEMU >security issues, as they come in. > > > Proposal: (to address above limitations) > = > > * We set up a new 'qemu-security' mailing list. > > * QEMU security issues are reported to this new list only. > > * Representatives from various communities subscribe to this list. (List maybe >moderated in the beginning.) > > * As QEMU issues come in, participants on the 'qemu-security' list shall >discuss and decide about how to triage them further. > > Please kindly let us know your views about it. I'd appreciate if you have any > suggestions/inputs/comments about the same. Hi Prasad, Great idea. Like other project, sometimes they have two mailing lists. The first is 'security', this list should contains the core developers. The second is 'predisclosure', the organization can participate this lists and discuss the disclosure process. But as for qemu, most of the security issues doesn't need an embargo date. I think one 'qemu-security' is ok. I think this mailing lists can contain the currently individuals and the some qemu developer and also some organizations who uses qemu. Thanks, Li Qiang > > > Thank you. > -- > Prasad J Pandit / Red Hat Product Security Team > 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D > >