llvm dev - Jun 2020 - [RFC] LLVM Security Group and Process

Thanks Zola,

I’d rather have point-contact people, instead of having mailing lists. I have a
few goals with this:
Listing particular people makes it clear who’s on the hook from your
organization
These people can still communicate internally, but are responsible to ensure
that the internal folks know what the LLVM process and disclosure restrictions
are
Listing a limited number of specific people helps make this part of their
official work within their company, and ideally those folks make sure they’re
not all unavailable at the same time
Mailing lists tend to attract chatter and lose focus

That being said, there’s certainly convenience to having a list. I’m not sure
that convenience warrants the tradeoffs :)

LMK what you think!

JF

> On Jun 17, 2020, at 3:52 PM, Zola Bridges <zbrid at google.com>
wrote:
> 
> Hi everyone!
> 
> I'm very glad this is moving forward! Just a week or two ago there was
an SLH bug that really should've been sent to a group like the one
that's being created here. Thanks a bunch, JF, for driving this!
> 
> I'd like to be in this group representing the C++ security team at
Google. I maintain two speculative execution side channel attack passes:
Speculative Load Hardening and Speculative Execution Side Effect Suppression.
> 
> I'd also like the mailing list alias llvm-security at google.com
<mailto:llvm-security at google.com> to be in this group. The list is
restricted within Google to folks who need to be involved in security response
related to LLVM.
> 
> Are there objections to this? I did read the proposal and it looks like
it's okay for members of the group to share vulnerabilities/reports within
their organization on a need-to-know basis, however it's possible a set up
like this is not what was intended by what was written in the proposal, so
I'd like to hear your thoughts.
> 
> Thanks again to everyone involved in setting this up!
> 
> Zola Bridges
> 
> 
> On Mon, Jun 15, 2020 at 11:56 AM Renato Golin via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Great idea! Sign me up, please!
> 
> On Fri, 12 Jun 2020 at 16:59, JF Bastien via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
> >
> > Great! On the Apple side, we’ll propose Oliver Hunt (clang team) and
Scotty Bolin (product security team), CC’ed to this email.
> >
> >
> > On Jun 12, 2020, at 6:50 AM, Kristof Beyls <Kristof.Beyls at
arm.com <mailto:Kristof.Beyls at arm.com>> wrote:
> >
> > Thank you for progressing this, JF!
> >
> > As vendor contacts for Arm, myself (kristof.beyls at arm.com
<mailto:kristof.beyls at arm.com>) and Peter Smith (peter.smith at arm.com
<mailto:peter.smith at arm.com>) are interested in being part of the
Security Group.
> > We’re also interested in helping in the forming of this group.
> >
> > Thanks,
> >
> > Kristof
> >
> > On 11 Jun 2020, at 17:39, JF Bastien via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
> > Hi security-minded folks!
> >
> > I published this RFC quite a while ago, and have received good
feedback from y’all, as well as enthusiasm from a few folks whose distribution
would benefit from having a security process for LLVM. Arnaud and the Board
approved the patch a few weeks ago, I’ll therefore commit it in the next few
days and start moving the missing parts forward.
> >
> > Some folks have self-identified as being interested in being part of
the original Security Group. Let’s take this opportunity to hear from anyone
else who’s interested: please speak up!
> >
> > Thanks,
> >
> > JF
> >
> >
> > On Nov 15, 2019, at 10:58 AM, JF Bastien via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
> > Hello compiler enthusiasts,
> >
> >
> > The Apple LLVM team would like to propose that a new a security
process and an associated private LLVM Security Group be created under the
umbrella of the LLVM project.
> >
> > A draft proposal for how we could organize such a group and what its
process could be is available on Phabricator. The proposal starts with a list of
goals for the process and Security Group, repeated here:
> >
> > The LLVM Security Group has the following goals:
> >
> > Allow LLVM contributors and security researchers to disclose
security-related issues affecting the LLVM project to members of the LLVM
community.
> > Organize fixes, code reviews, and release management for said issues.
> > Allow distributors time to investigate and deploy fixes before wide
dissemination of vulnerabilities or mitigation shortcomings.
> > Ensure timely notification and release to vendors who package and
distribute LLVM-based toolchains and projects.
> > Ensure timely notification to users of LLVM-based toolchains whose
compiled code is security-sensitive, through the CVE process.
> >
> >
> > We’re looking for answers to the following questions:
> >
> > On this list: Should we create a security group and process?
> > On this list: Do you agree with the goals listed in the proposal?
> > On this list: at a high-level, what do you think should be done
differently, and what do you think is exactly right in the draft proposal?
> > On the Phabricator code review: going into specific details, what do
you think should be done differently, and what do you think is exactly right in
the draft proposal?
> > On this list: to help understand where you’re coming from with your
feedback, it would be helpful to state how you personally approach this issue:
> >
> > Are you an LLVM contributor (individual or representing a company)?
> > Are you involved with security aspects of LLVM (if so, which)?
> > Do you maintain significant downstream LLVM changes?
> > Do you package and deploy LLVM for others to use (if so, to how many
people)?
> > Is your LLVM distribution based on the open-source releases?
> > How often do you usually deploy LLVM?
> > How fast can you deploy an update?
> > Does your LLVM distribution handle untrusted inputs, and what kind?
> > What’s the threat model for your LLVM distribution?
> >
> >
> > Other open-source projects have security-related groups and processes.
They structure their group very differently from one another. This proposal
borrows from some of these projects’ processes. A few examples:
> >
> > https://webkit.org/security-policy/
<https://webkit.org/security-policy/>
> >
https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md
<https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md>
> > https://wiki.mozilla.org/Security
<https://wiki.mozilla.org/Security>
> > https://www.openbsd.org/security.html
<https://www.openbsd.org/security.html>
> > https://security-team.debian.org/security_tracker.html
<https://security-team.debian.org/security_tracker.html>
> > https://www.python.org/news/security/
<https://www.python.org/news/security/>
> >
> > When providing feedback, it would be great to hear if you’ve dealt
with these or other projects’ processes, what works well, and what can be done
better.
> >
> >
> > I’ll go first in answering my own questions above:
> >
> > Yes! We should create a security group and process.
> > We agree with the goals listed.
> > We think the proposal is exactly right, but would like to hear the
community’s opinions.
> > Here’s how we approach the security of LLVM:
> >
> > I contribute to LLVM as an Apple employee.
> > I’ve been involved in a variety of LLVM security issues, from
automatic variable initialization to security-related diagnostics, as well as
deploying these mitigations to internal codebases.
> > We maintain significant downstream changes.
> > We package and deploy LLVM, both internally and externally, for a
variety of purposes, including the clang, Swift, and mobile GPU shader
compilers.
> > Our LLVM distribution is not directly derived from the open-source
release. In all cases, all non-upstream public patches for our releases are
available in repository branches at https://github.com/apple
<https://github.com/apple>.
> > We have many deployments of LLVM whose release schedules vary
significantly. The LLVM build deployed as part of Xcode historically has one
major release per year, followed by roughly one minor release every 2 months.
Other releases of LLVM are also security-sensitive and don’t follow the same
schedule.
> > This depends on which release of LLVM is affected.
> > Yes, our distribution sometimes handles untrusted input.
> > The threat model is highly variable depending on the particular
language front-ends being considered.
> >
> > Apple is involved with a variety of open-source projects and their
disclosures. For example, we frequently work with the WebKit community to handle
security issues through their process.
> >
> >
> > Thanks,
> >
> > JF
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200617/d3c115c8/attachment.html>

Hi JF,

Thanks for the quick response!

The biggest reason I think the mailing list would make sense is to avoid a
single point of failure within Google. While folks like me and kcc will be
the active participants in the group, the mailing list means that any
security responders at Google who may need to know this information about a
particular issue will have access even if me or kcc (or any other Googler)
are all unavailable.

Keeping me, kcc, and other Googlers who end up joining as top-level members
with their info listed the same as other members seems like it would
address the 1st and 3rd points.

I think it would make sense if the mailing list had read-only access to
limit chatter to address the 4th point. This mailing list isn't intended to
be a new set of active participants, but is intended to keep relevant
Googlers in the loop for relevant vulnerabilities.

The 2nd point is important and folks on the Google-internal list will have
expectations set when they join the list. In addition, typically the folks
on the list will be those at Google who already work with security incident
response and have baseline knowledge about general expectations for lists
such as this one.

Zola Bridges


On Wed, Jun 17, 2020 at 3:59 PM JF Bastien <jfbastien at apple.com> wrote:
> Thanks Zola,
>
> I’d rather have point-contact people, instead of having mailing lists. I
> have a few goals with this:
>
>    1. Listing particular people makes it clear who’s on the hook from
>    your organization
>    2. These people can still communicate internally, but are responsible
>    to ensure that the internal folks know what the LLVM process and
disclosure
>    restrictions are
>    3. Listing a limited number of specific people helps make this part of
>    their official work within their company, and ideally those folks make
sure
>    they’re not all unavailable at the same time
>    4. Mailing lists tend to attract chatter and lose focus
>
>
> That being said, there’s certainly convenience to having a list. I’m not
> sure that convenience warrants the tradeoffs :)
>
> LMK what you think!
>
> JF
>
>
> On Jun 17, 2020, at 3:52 PM, Zola Bridges <zbrid at google.com>
wrote:
>
> Hi everyone!
>
> I'm very glad this is moving forward! Just a week or two ago there was
an
> SLH bug that really should've been sent to a group like the one
that's
> being created here. Thanks a bunch, JF, for driving this!
>
> I'd like to be in this group representing the C++ security team at
Google.
> I maintain two speculative execution side channel attack passes:
> Speculative Load Hardening and Speculative Execution Side Effect
> Suppression.
>
> I'd also like the mailing list alias llvm-security at google.com to be
in
> this group. The list is restricted within Google to folks who need to be
> involved in security response related to LLVM.
>
> Are there objections to this? I did read the proposal and it looks like
> it's okay for members of the group to share vulnerabilities/reports
within
> their organization on a need-to-know basis, however it's possible a set
up
> like this is not what was intended by what was written in the proposal, so
> I'd like to hear your thoughts.
>
> Thanks again to everyone involved in setting this up!
>
> Zola Bridges
>
>
> On Mon, Jun 15, 2020 at 11:56 AM Renato Golin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Great idea! Sign me up, please!
>>
>> On Fri, 12 Jun 2020 at 16:59, JF Bastien via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> >
>> > Great! On the Apple side, we’ll propose Oliver Hunt (clang team)
and
>> Scotty Bolin (product security team), CC’ed to this email.
>> >
>> >
>> > On Jun 12, 2020, at 6:50 AM, Kristof Beyls <Kristof.Beyls at
arm.com>
>> wrote:
>> >
>> > Thank you for progressing this, JF!
>> >
>> > As vendor contacts for Arm, myself (kristof.beyls at arm.com) and
Peter
>> Smith (peter.smith at arm.com) are interested in being part of the
Security
>> Group.
>> > We’re also interested in helping in the forming of this group.
>> >
>> > Thanks,
>> >
>> > Kristof
>> >
>> > On 11 Jun 2020, at 17:39, JF Bastien via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>> >
>> > Hi security-minded folks!
>> >
>> > I published this RFC quite a while ago, and have received good
feedback
>> from y’all, as well as enthusiasm from a few folks whose distribution
would
>> benefit from having a security process for LLVM. Arnaud and the Board
>> approved the patch a few weeks ago, I’ll therefore commit it in the
next
>> few days and start moving the missing parts forward.
>> >
>> > Some folks have self-identified as being interested in being part
of
>> the original Security Group. Let’s take this opportunity to hear from
>> anyone else who’s interested: please speak up!
>> >
>> > Thanks,
>> >
>> > JF
>> >
>> >
>> > On Nov 15, 2019, at 10:58 AM, JF Bastien via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>> >
>> > Hello compiler enthusiasts,
>> >
>> >
>> > The Apple LLVM team would like to propose that a new a security
process
>> and an associated private LLVM Security Group be created under the
umbrella
>> of the LLVM project.
>> >
>> > A draft proposal for how we could organize such a group and what
its
>> process could be is available on Phabricator. The proposal starts with
a
>> list of goals for the process and Security Group, repeated here:
>> >
>> > The LLVM Security Group has the following goals:
>> >
>> > Allow LLVM contributors and security researchers to disclose
>> security-related issues affecting the LLVM project to members of the
LLVM
>> community.
>> > Organize fixes, code reviews, and release management for said
issues.
>> > Allow distributors time to investigate and deploy fixes before
wide
>> dissemination of vulnerabilities or mitigation shortcomings.
>> > Ensure timely notification and release to vendors who package and
>> distribute LLVM-based toolchains and projects.
>> > Ensure timely notification to users of LLVM-based toolchains whose
>> compiled code is security-sensitive, through the CVE process.
>> >
>> >
>> > We’re looking for answers to the following questions:
>> >
>> > On this list: Should we create a security group and process?
>> > On this list: Do you agree with the goals listed in the proposal?
>> > On this list: at a high-level, what do you think should be done
>> differently, and what do you think is exactly right in the draft
proposal?
>> > On the Phabricator code review: going into specific details, what
do
>> you think should be done differently, and what do you think is exactly
>> right in the draft proposal?
>> > On this list: to help understand where you’re coming from with
your
>> feedback, it would be helpful to state how you personally approach this
>> issue:
>> >
>> > Are you an LLVM contributor (individual or representing a
company)?
>> > Are you involved with security aspects of LLVM (if so, which)?
>> > Do you maintain significant downstream LLVM changes?
>> > Do you package and deploy LLVM for others to use (if so, to how
many
>> people)?
>> > Is your LLVM distribution based on the open-source releases?
>> > How often do you usually deploy LLVM?
>> > How fast can you deploy an update?
>> > Does your LLVM distribution handle untrusted inputs, and what
kind?
>> > What’s the threat model for your LLVM distribution?
>> >
>> >
>> > Other open-source projects have security-related groups and
processes.
>> They structure their group very differently from one another. This
proposal
>> borrows from some of these projects’ processes. A few examples:
>> >
>> > https://webkit.org/security-policy/
>> >
>>
https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md
>> > https://wiki.mozilla.org/Security
>> > https://www.openbsd.org/security.html
>> > https://security-team.debian.org/security_tracker.html
>> > https://www.python.org/news/security/
>> >
>> > When providing feedback, it would be great to hear if you’ve dealt
with
>> these or other projects’ processes, what works well, and what can be
done
>> better.
>> >
>> >
>> > I’ll go first in answering my own questions above:
>> >
>> > Yes! We should create a security group and process.
>> > We agree with the goals listed.
>> > We think the proposal is exactly right, but would like to hear the
>> community’s opinions.
>> > Here’s how we approach the security of LLVM:
>> >
>> > I contribute to LLVM as an Apple employee.
>> > I’ve been involved in a variety of LLVM security issues, from
automatic
>> variable initialization to security-related diagnostics, as well as
>> deploying these mitigations to internal codebases.
>> > We maintain significant downstream changes.
>> > We package and deploy LLVM, both internally and externally, for a
>> variety of purposes, including the clang, Swift, and mobile GPU shader
>> compilers.
>> > Our LLVM distribution is not directly derived from the open-source
>> release. In all cases, all non-upstream public patches for our releases
are
>> available in repository branches at https://github.com/apple.
>> > We have many deployments of LLVM whose release schedules vary
>> significantly. The LLVM build deployed as part of Xcode historically
has
>> one major release per year, followed by roughly one minor release every
2
>> months. Other releases of LLVM are also security-sensitive and don’t
follow
>> the same schedule.
>> > This depends on which release of LLVM is affected.
>> > Yes, our distribution sometimes handles untrusted input.
>> > The threat model is highly variable depending on the particular
>> language front-ends being considered.
>> >
>> > Apple is involved with a variety of open-source projects and their
>> disclosures. For example, we frequently work with the WebKit community
to
>> handle security issues through their process.
>> >
>> >
>> > Thanks,
>> >
>> > JF
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200617/7175487e/attachment.html>

Hi everyone,

I followed up with some folks at Google about how we wanted to be involved
in this group and we decided that Matthew Riley (mattdr at google.com) would
be the right person to be involved here.

Sorry about the confusion. I'd like to withdraw my request.

Thanks again to everyone involved! I'm glad to see this becoming a part of
how LLVM works. :)

Zola Bridges


On Wed, Jun 17, 2020 at 4:52 PM Zola Bridges <zbrid at google.com> wrote:
> Hi JF,
>
> Thanks for the quick response!
>
> The biggest reason I think the mailing list would make sense is to avoid a
> single point of failure within Google. While folks like me and kcc will be
> the active participants in the group, the mailing list means that any
> security responders at Google who may need to know this information about a
> particular issue will have access even if me or kcc (or any other Googler)
> are all unavailable.
>
> Keeping me, kcc, and other Googlers who end up joining as top-level
> members with their info listed the same as other members seems like it
> would address the 1st and 3rd points.
>
> I think it would make sense if the mailing list had read-only access to
> limit chatter to address the 4th point. This mailing list isn't
intended to
> be a new set of active participants, but is intended to keep relevant
> Googlers in the loop for relevant vulnerabilities.
>
> The 2nd point is important and folks on the Google-internal list will have
> expectations set when they join the list. In addition, typically the folks
> on the list will be those at Google who already work with security incident
> response and have baseline knowledge about general expectations for lists
> such as this one.
>
> Zola Bridges
>
>
> On Wed, Jun 17, 2020 at 3:59 PM JF Bastien <jfbastien at apple.com>
wrote:
>
>> Thanks Zola,
>>
>> I’d rather have point-contact people, instead of having mailing lists.
I
>> have a few goals with this:
>>
>>    1. Listing particular people makes it clear who’s on the hook from
>>    your organization
>>    2. These people can still communicate internally, but are
responsible
>>    to ensure that the internal folks know what the LLVM process and
disclosure
>>    restrictions are
>>    3. Listing a limited number of specific people helps make this part
>>    of their official work within their company, and ideally those folks
make
>>    sure they’re not all unavailable at the same time
>>    4. Mailing lists tend to attract chatter and lose focus
>>
>>
>> That being said, there’s certainly convenience to having a list. I’m
not
>> sure that convenience warrants the tradeoffs :)
>>
>> LMK what you think!
>>
>> JF
>>
>>
>> On Jun 17, 2020, at 3:52 PM, Zola Bridges <zbrid at google.com>
wrote:
>>
>> Hi everyone!
>>
>> I'm very glad this is moving forward! Just a week or two ago there
was an
>> SLH bug that really should've been sent to a group like the one
that's
>> being created here. Thanks a bunch, JF, for driving this!
>>
>> I'd like to be in this group representing the C++ security team at
>> Google. I maintain two speculative execution side channel attack
passes:
>> Speculative Load Hardening and Speculative Execution Side Effect
>> Suppression.
>>
>> I'd also like the mailing list alias llvm-security at google.com to
be in
>> this group. The list is restricted within Google to folks who need to
be
>> involved in security response related to LLVM.
>>
>> Are there objections to this? I did read the proposal and it looks like
>> it's okay for members of the group to share vulnerabilities/reports
within
>> their organization on a need-to-know basis, however it's possible a
set up
>> like this is not what was intended by what was written in the proposal,
so
>> I'd like to hear your thoughts.
>>
>> Thanks again to everyone involved in setting this up!
>>
>> Zola Bridges
>>
>>
>> On Mon, Jun 15, 2020 at 11:56 AM Renato Golin via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Great idea! Sign me up, please!
>>>
>>> On Fri, 12 Jun 2020 at 16:59, JF Bastien via llvm-dev
>>> <llvm-dev at lists.llvm.org> wrote:
>>> >
>>> > Great! On the Apple side, we’ll propose Oliver Hunt (clang
team) and
>>> Scotty Bolin (product security team), CC’ed to this email.
>>> >
>>> >
>>> > On Jun 12, 2020, at 6:50 AM, Kristof Beyls <Kristof.Beyls
at arm.com>
>>> wrote:
>>> >
>>> > Thank you for progressing this, JF!
>>> >
>>> > As vendor contacts for Arm, myself (kristof.beyls at arm.com)
and Peter
>>> Smith (peter.smith at arm.com) are interested in being part of the
>>> Security Group.
>>> > We’re also interested in helping in the forming of this group.
>>> >
>>> > Thanks,
>>> >
>>> > Kristof
>>> >
>>> > On 11 Jun 2020, at 17:39, JF Bastien via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>> >
>>> > Hi security-minded folks!
>>> >
>>> > I published this RFC quite a while ago, and have received good
>>> feedback from y’all, as well as enthusiasm from a few folks whose
>>> distribution would benefit from having a security process for LLVM.
Arnaud
>>> and the Board approved the patch a few weeks ago, I’ll therefore
commit it
>>> in the next few days and start moving the missing parts forward.
>>> >
>>> > Some folks have self-identified as being interested in being
part of
>>> the original Security Group. Let’s take this opportunity to hear
from
>>> anyone else who’s interested: please speak up!
>>> >
>>> > Thanks,
>>> >
>>> > JF
>>> >
>>> >
>>> > On Nov 15, 2019, at 10:58 AM, JF Bastien via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>> >
>>> > Hello compiler enthusiasts,
>>> >
>>> >
>>> > The Apple LLVM team would like to propose that a new a
security
>>> process and an associated private LLVM Security Group be created
under the
>>> umbrella of the LLVM project.
>>> >
>>> > A draft proposal for how we could organize such a group and
what its
>>> process could be is available on Phabricator. The proposal starts
with a
>>> list of goals for the process and Security Group, repeated here:
>>> >
>>> > The LLVM Security Group has the following goals:
>>> >
>>> > Allow LLVM contributors and security researchers to disclose
>>> security-related issues affecting the LLVM project to members of
the LLVM
>>> community.
>>> > Organize fixes, code reviews, and release management for said
issues.
>>> > Allow distributors time to investigate and deploy fixes before
wide
>>> dissemination of vulnerabilities or mitigation shortcomings.
>>> > Ensure timely notification and release to vendors who package
and
>>> distribute LLVM-based toolchains and projects.
>>> > Ensure timely notification to users of LLVM-based toolchains
whose
>>> compiled code is security-sensitive, through the CVE process.
>>> >
>>> >
>>> > We’re looking for answers to the following questions:
>>> >
>>> > On this list: Should we create a security group and process?
>>> > On this list: Do you agree with the goals listed in the
proposal?
>>> > On this list: at a high-level, what do you think should be
done
>>> differently, and what do you think is exactly right in the draft
proposal?
>>> > On the Phabricator code review: going into specific details,
what do
>>> you think should be done differently, and what do you think is
exactly
>>> right in the draft proposal?
>>> > On this list: to help understand where you’re coming from with
your
>>> feedback, it would be helpful to state how you personally approach
this
>>> issue:
>>> >
>>> > Are you an LLVM contributor (individual or representing a
company)?
>>> > Are you involved with security aspects of LLVM (if so, which)?
>>> > Do you maintain significant downstream LLVM changes?
>>> > Do you package and deploy LLVM for others to use (if so, to
how many
>>> people)?
>>> > Is your LLVM distribution based on the open-source releases?
>>> > How often do you usually deploy LLVM?
>>> > How fast can you deploy an update?
>>> > Does your LLVM distribution handle untrusted inputs, and what
kind?
>>> > What’s the threat model for your LLVM distribution?
>>> >
>>> >
>>> > Other open-source projects have security-related groups and
processes.
>>> They structure their group very differently from one another. This
proposal
>>> borrows from some of these projects’ processes. A few examples:
>>> >
>>> > https://webkit.org/security-policy/
>>> >
>>>
https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md
>>> > https://wiki.mozilla.org/Security
>>> > https://www.openbsd.org/security.html
>>> > https://security-team.debian.org/security_tracker.html
>>> > https://www.python.org/news/security/
>>> >
>>> > When providing feedback, it would be great to hear if you’ve
dealt
>>> with these or other projects’ processes, what works well, and what
can be
>>> done better.
>>> >
>>> >
>>> > I’ll go first in answering my own questions above:
>>> >
>>> > Yes! We should create a security group and process.
>>> > We agree with the goals listed.
>>> > We think the proposal is exactly right, but would like to hear
the
>>> community’s opinions.
>>> > Here’s how we approach the security of LLVM:
>>> >
>>> > I contribute to LLVM as an Apple employee.
>>> > I’ve been involved in a variety of LLVM security issues, from
>>> automatic variable initialization to security-related diagnostics,
as well
>>> as deploying these mitigations to internal codebases.
>>> > We maintain significant downstream changes.
>>> > We package and deploy LLVM, both internally and externally,
for a
>>> variety of purposes, including the clang, Swift, and mobile GPU
shader
>>> compilers.
>>> > Our LLVM distribution is not directly derived from the
open-source
>>> release. In all cases, all non-upstream public patches for our
releases are
>>> available in repository branches at https://github.com/apple.
>>> > We have many deployments of LLVM whose release schedules vary
>>> significantly. The LLVM build deployed as part of Xcode
historically has
>>> one major release per year, followed by roughly one minor release
every 2
>>> months. Other releases of LLVM are also security-sensitive and
don’t follow
>>> the same schedule.
>>> > This depends on which release of LLVM is affected.
>>> > Yes, our distribution sometimes handles untrusted input.
>>> > The threat model is highly variable depending on the
particular
>>> language front-ends being considered.
>>> >
>>> > Apple is involved with a variety of open-source projects and
their
>>> disclosures. For example, we frequently work with the WebKit
community to
>>> handle security issues through their process.
>>> >
>>> >
>>> > Thanks,
>>> >
>>> > JF
>>> >
>>> > _______________________________________________
>>> > LLVM Developers mailing list
>>> > llvm-dev at lists.llvm.org
>>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> >
>>> >
>>> > _______________________________________________
>>> > LLVM Developers mailing list
>>> > llvm-dev at lists.llvm.org
>>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > LLVM Developers mailing list
>>> > llvm-dev at lists.llvm.org
>>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200618/5db5dbb6/attachment.html>