similar to: [RFC] LLVM Security Group and Process

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

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

I think it's great to make a policy for reporting security bugs. But first, yes, we need to be clear as to what sorts of things we consider as "security bugs", and what we do not. We need to be clear on this, both for users to know what they should depend on, and for LLVM contributors to know when they should be raising a flag, if they discover or fix something themselves. We could

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

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

On Mon, Nov 18, 2019 at 2:31 PM Robinson, Paul via llvm-dev < llvm-dev at lists.llvm.org> wrote: > One problem with defining away “arbitrary code execution in Clang” as “not > security relevant” is that you are inevitably making probably-wrong > assumptions about the set of all possible execution contexts. > > > > Case in point: Sony, being on the security-sensitive

Hello fans of the auto keyword! We now have a policy on how LLVM toolchains get updated <https://reviews.llvm.org/rL351765>! Let’s put that policy to good use, and talk about how we’ll move all monorepo projects past C++11. Previous Discussions LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond! <http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>" A Short

+1, thanks again for driving this. On Fri, Jan 25, 2019 at 3:57 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The discussion seems to have died down and gotten good consensus. I’ve > therefore create a patch which applies the proposed soft-errors: > > https://reviews.llvm.org/D57264 > > > We’ll only migrate to hard-error (and start using new

Hi folks! Six more months have come and gone, and maybe we could move LLVM to C++14 now? The issues I picked out from the last discussion: Some folks want an official policy about compiler support before updating the standard version we use. Worries about which GCC version is available in which distro. Worries about MSVC. Instead of rehashing the compiler per distro surveys from previous

Consider me on board with the highest version we can come to an agreement on :) On Thu, May 10, 2018 at 11:50 AM JF Bastien <jfbastien at apple.com> wrote: > > On May 10, 2018, at 11:35 AM, Zachary Turner <zturner at google.com> wrote: > > If it's the only thing we can agree then I'll take it, but I just worry > that 3 years from now we're going to start

On Mon, Apr 1, 2019 at 1:16 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello folks (except fans of April 1st: this is *not* a joke), > > We discussed migrating past C++11 > <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html> recently > and got consensus. This led us to bump our minimum toolchain requirements >

> On Apr 1, 2019, at 4:10 PM, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Apr 1, 2019, at 4:07 PM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote: >> >> On Mon, Apr 1, 2019 at 1:16 PM JF Bastien via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>

> On May 6, 2019, at 11:02 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > > I know you'll be shocked that we've slipped in our efforts. ;] I don't have a super meaningful ETA update though -- a bunch of unknows have been found and addressed, and again, I feel like we might finish this in roughly a month. > > On the flip side, I do want to clarify the

Windows has never been the issue. Honestly, MSVC on Windows is "fully C++17 conformant" [1]. The issue has and always will be GCC. Given that a bump in any version of GCC has been (and will remain) difficult for some time, I propose that we skip C++14 and move to 17. We don't want to have a multi-year disccusion about this again any time soon, and from what I gather, nobody has

On Mon, May 6, 2019 at 2:44 PM James Y Knight <jyknight at google.com> wrote: > Given the small number of library features added by c++14, and given that > they were mostly already implemented in libstdc++ 4.9 [1], I suspect that > moving to c++14 with that stdlib as the minimum probably will not actually > cause friction for developers who are using normal toolchains to be able

If it's the only thing we can agree then I'll take it, but I just worry that 3 years from now we're going to start another 3 year discussion, so that any actual move to C++17 would end up taking double the time. Are the issues specific to C++17 additions to the standard library? What if you allow C++17 language features but not C++17 library features? I'm guessing this is too

Last time this came up, there were a lot of people that were stuck on GCC 4.9 due to ABI reasons. I think forcing that upgrade is going to be the most disruptive part of this, and I think that will really need a decent amount of time. =[ On Thu, May 10, 2018 at 2:26 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On May 10, 2018, at 12:25 PM, Evgeny Astigeevich

Well… Ubuntu 16.04 came with gcc 5, and deploying Visual Studio 2015 should be a done deal in Windows shops, which suggests moving to C++14 should be no problem. It's nice to see this week's version of MSVC supports C++17 but deploying through corporate IT can take a while. ("This week's version" because the blog post is dated Monday.) --paulr From: llvm-dev

I'm happy to announce that Google has migrated to libc++, and we're ready for C++14 and beyond. JF, what are the remaining blockers? /Eric On Mon, May 6, 2019 at 5:12 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On May 6, 2019, at 2:08 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > > On Mon, May 6, 2019 at 2:44 PM James Y

Hi, IMHO, it’s a good idea to move to C++14 first. What do you think about doing this by two phases: Phase1: require GCC >= 5 but build in C++11 mode (this will give time to adapt build infrastructure to a new gcc) Phase2: switch to C++14 Thanks, Evgeny From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org>