Date: Sun, 16 May 2021 09:39:19 +0200
Isabella,
thanks for the nice explanation!
Regards
Peter
Sent from Peter Sommerlad's iPad
+41 79 432 23 32
> On 16 May 2021, at 03:39, Isabella Muerte via SG7 <sg7_at_[hidden]> wrote:
>
>
> I would just like to mention that with clang and gcc plugins *anything* is possible as well, and even trusting that your build system is printing out the correct command that it is executing (even if its defined in your Makefile or build.ninja) is also a level of implicit trust that we all currently exhibit in our builds. There is, quite honestly, very few things stopping a make implementation or ninja installation from detecting your compiler, injecting something with -plugin, and printing out something different. On some platforms it's possible to detect what programs might be watching or logging behavior through tools like detours, ptrace, or even mach ports, which allows for hiding this behavior under observation. Some folks also just inject assembly that is never executed, but will cause disassemblers to crash.
>
> Right now the ability for Rust proc-macros[^1] to "execute anything" is a known issue (Mara Bos, the maintainer of wg21.link, for instance showed a "SFINAE in Rust" tweet where she just calls fork() on the compiler to find the correct code that compiles out of a given set of statements.
>
> Specifications like WASM (not WASI[^2], which gives access to certain system level resources) do a lot to alleviate this. There are hard restrictions on WASM that can be further reduced by the host's choice and escaping WASM is much harder to do (especially if there is no JIT, but instead a simple bytecode interpreter). There's also some literature[1] on static analysis of stack based VM instruction sets that show someone can statically analyze how valid a given instruction sequence is, and if it violates anything the host might consider to be incorrect, invalid, or undefined behavior[^3].
>
> Rust's MIR interpreter[2] predates WASM 1.0, and if it were to be retrofitted to support it, it would have to have MIR intrinsics due to the additional use of metadata and behavior it tries to diagnose. However, the only thing truly stopping Rust plugins from compiling to WASM is the lack of the reference types[3] and function-ref papers added to the WASM specification. It could most likely end up within the Rust compiler itself at some point as it would only be an ABI break, not an API break.
>
> That said, having spoken with Mara and @eddyb from github (who is effectively the author of the protocol for which proc-macros can speak with the rust compiler), the Rust compiler team is actually working to lock some of these things down, however the core compiler team is only a bit larger than the team working on MSVC.
>
> Regarding reflection, even if we specify it in such a way that it cannot do arbitrary things, as long as compilers have a mechanism to communicate with a process outside, anything is possible. Trying to design it to be as sandboxed as possible is, quite honestly, like trying to solve the piracy issue in game development.
>
> [1]: "Virtual Machines" *Iain D. Craig *ISBN-13: 978-1849969802
> [2]: https://github.com/rust-lang/miri
> [3]: https://github.com/WebAssembly/reference-types
>
> [^1]: Not to be confused with the hygenic macro syntax, proc-macros are compiled as a plugin against the Rust compiler. Hygenic macros do not suffer from this issue, as they only operate on the AST with a custom syntax.
>
> [^2]: In part based off of the work done on CloudABI, to the point that when WASI was announced some of the documentation was copied word for word, though the CloudABI people didn't make a fuss about it. WASI allows for things like file I/O and networking, however its specified in such a way that even these can be sandboxed by a host if desired.
>
> [^3]: Iain Craig details how both the JVM and CLR (at the time of writing in 2005, things have changed since then of course) allow for analysis of allowed (but undesired) behavior. However I believe to date, no one has taken advantage of the work detailed in the book and finding the book itself is in fact very difficult these days, looking at prices on Amazon and elsewhere.
>
> On Sat, May 15, 2021, at 16:55, JF Bastien via SG7 wrote:
> > I think I understand what you’re saying... and yes I agree that reflection should not do arbitrary stuff at compile time.
> >
> > That said, today’s compilers are already not implemented to recent this type of attack at all. You can exploit a compiler way easier than say a web browser. Reflection won’t open a Pandora box all of a sudden... but we should still design it in a way that’s bounded 🙂
> >
> >
> > On Sat, May 15, 2021 at 4:49 PM Herb Sutter <hsutter_at_[hidden]> wrote:
> >> I should tease apart two things:____
>
> >> __ __
>
> >> Yes, the general issue is the ability to link and run arbitrary libs at compile time. That’s the main point below, a concern we had that appears to be arising in the wild for languages that went down that path.____
>
> >> __ __
>
> >> But, secondarily, I thought it’s also related to the narrower issue of Trusting Trust attacks because Thompson’s initial approach required a specially-crafted compiler binary that already carried the malicious code, whereas the ability to execute arbitrary libraries at compile time (esp. malicious ones that can do introspection) could give a new vector to inject Trusting Trust attacks… the compiler can be totally pristine, but comes with a launchpad to let you provide the malicious code later. No?____
>
> >> __ __
>
> >> __ __
>
> >> __ __
>
> >>
>
> >> *From:* JF Bastien <cxx_at_[hidden]>
> >> *Sent:* Saturday, May 15, 2021 3:34 PM
> >> *To:* sg7_at_[hidden]
> >> *Cc:* Hana Dusíková <hanicka_at_[hidden]>; Chandler Carruth <chandlerc_at_[hidden]>; Herb Sutter <hsutter_at_[hidden]>
> >> *Subject:* Re: [SG7] Thompson Turing lecture____
> >>
>
> >> __ __
>
> >> It's not really the same issue: trusting trust is about the compiler changing the code it's compiling (including changing a compiler it's compiling to continue having this behavior), whereas the Rust thing is that macros can execute arbitrary Rust including networking code. The Rust problem is equivalent to putting arbitrary code in your makefile. It's something that you could sandbox and disallow (say, by running the compiler in a container). Whereas trusting trust is very hard to detect because the compiler's output binary is what's been compromised and you can't easily tell.____
>
> >> __ __
>
> >> On Sat, May 15, 2021 at 3:24 PM Herb Sutter via SG7 <sg7_at_[hidden]> wrote:____
>
> >>> Below, I emailed the “Trusting Trust” reference during our SG7 session on Circle in Prague, because SG7 was in the middle of discussing concerns about Circle’s approach of linking arbitrary libraries and executing them at compile time.____
>
> >>> ____
>
> >>> Since yesterday, I noticed the following tweets about Rust…____
>
> >>> ____
>
> >>> Tony “Abolish ICE” Arcieri 🦀 on Twitter: "Exfiltrating secrets with @rustlang macros: leveraging macro expansion in IDEs to exfiltrate secrets without compiling the code or even opening a file https://t.co/M2qhsfaLdX" / Twitter <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fbascule%2Fstatus%2F1393228285056741376&data=04%7C01%7Chsutter%40microsoft.com%7C961ce426a36a4eaf8e9908d917f185a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637567148365841167%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=G267zWwO9AX%2F3O0NRhQiGMIJJ8CD2A66ksYKok9as0I%3D&reserved=0>____
>
> >>> ____
>
> >>> Ralf (RPW) on Twitter: "„Open innocent_app in VSCode*, and the contents of your .ssh/id_rsa file will be sent over TCP to localhost:8080. You don't even need to open any files in the project!“ https://t.co/eKx2CWrirD" / Twitter <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fesizkur%2Fstatus%2F1393477018474459137&data=04%7C01%7Chsutter%40microsoft.com%7C961ce426a36a4eaf8e9908d917f185a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637567148365851162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=8WgNZXJKVCoFeUgU4lOGmrSRN%2FEJwDnIvy5BptZkOyo%3D&reserved=0>____
>
> >>> ____
>
> >>> Björk on Twitter: "@hankadusikova ... Wait, what? You can do compile-time I/O (networking) in Rust, or is this because of plugins executing arbitrary code? https://t.co/soA3bD9vT2" / Twitter <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2F__phantomderp%2Fstatus%2F1393553321177321473&data=04%7C01%7Chsutter%40microsoft.com%7C961ce426a36a4eaf8e9908d917f185a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637567148365861161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=JYRYlAxAlIj874btarG5yVdqa4WwFanyYIqCeJ%2FP9hU%3D&reserved=0>____
>
> >>> ____
>
> >>> David "Bear Feeder" Pollak🐈 on Twitter: "Oh crap! This will be 2021’s side channel attack… guess we have to run our compilers in containers with no network access…" / Twitter <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fdpp%2Fstatus%2F1393614418269802501&data=04%7C01%7Chsutter%40microsoft.com%7C961ce426a36a4eaf8e9908d917f185a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637567148365871158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=FN7TEy1emthwaJa4IX4NwgKa8LyGdcx1%2BtJ7tL34GK0%3D&reserved=0>____
>
> >>> ____
>
> >>> This sounds a lot like the same issue… is it?____
>
> >>> ____
>
> >>> (Ah, I just saw Hana’s tweet <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fhankadusikova%2Fstatus%2F1393532440120074243%3Fs%3D20&data=04%7C01%7Chsutter%40microsoft.com%7C961ce426a36a4eaf8e9908d917f185a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637567148365881150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=B5%2F3HwNOjk10s1UcxOJ7N6k0qpbCU1ldT4Qhthpxj%2BM%3D&reserved=0> before hitting Send – yup, sounds like it is the same issue, thank you Hana.)____
>
> >>> ____
>
> >>> ____
>
> >>> ____
>
> >>>
>
> >>> *From:* Herb Sutter
> >>> *Sent:* Thursday, February 13, 2020 7:59 AM
> >>> *To:* sg7_at_[hidden]
> >>> *Subject:* Thompson Turing lecture____
> >>>
>
> >>> ____
>
> >>> https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf <https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.cs.cmu.edu%2F~rdriley%2F487%2Fpapers%2FThompson_1984_ReflectionsonTrustingTrust.pdf&data=04%7C01%7Chsutter%40microsoft.com%7C961ce426a36a4eaf8e9908d917f185a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637567148365881150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=qWJ5TJJ1LacYSAnZqFU6fiulR6iyb5CNlMF1skn72Vo%3D&reserved=0>____
>
> >>> ____
>
> >>> As we we think about extensible compilers and JITs, this is a classic paper worth remembering about supply chain issues with just ordinary closed compilers.____
>
> >>> ____
>
> >>> Herb____
>
> >>> ____
>
> >>>
>
> >>> --
> >>> SG7 mailing list
> >>> SG7_at_[hidden]
> >>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C961ce426a36a4eaf8e9908d917f185a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637567148365891145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3ZKbFwRpHiQ3981DPNxSVWXndKEKo8Xj%2BB6FzcbLuj4%3D&reserved=0>____
> >>>
>
> > --
> > SG7 mailing list
> > SG7_at_[hidden] <mailto:SG7%40lists.isocpp.org>
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg7
> >
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
thanks for the nice explanation!
Regards
Peter
Sent from Peter Sommerlad's iPad
+41 79 432 23 32
> On 16 May 2021, at 03:39, Isabella Muerte via SG7 <sg7_at_[hidden]> wrote:
>
>
> I would just like to mention that with clang and gcc plugins *anything* is possible as well, and even trusting that your build system is printing out the correct command that it is executing (even if its defined in your Makefile or build.ninja) is also a level of implicit trust that we all currently exhibit in our builds. There is, quite honestly, very few things stopping a make implementation or ninja installation from detecting your compiler, injecting something with -plugin, and printing out something different. On some platforms it's possible to detect what programs might be watching or logging behavior through tools like detours, ptrace, or even mach ports, which allows for hiding this behavior under observation. Some folks also just inject assembly that is never executed, but will cause disassemblers to crash.
>
> Right now the ability for Rust proc-macros[^1] to "execute anything" is a known issue (Mara Bos, the maintainer of wg21.link, for instance showed a "SFINAE in Rust" tweet where she just calls fork() on the compiler to find the correct code that compiles out of a given set of statements.
>
> Specifications like WASM (not WASI[^2], which gives access to certain system level resources) do a lot to alleviate this. There are hard restrictions on WASM that can be further reduced by the host's choice and escaping WASM is much harder to do (especially if there is no JIT, but instead a simple bytecode interpreter). There's also some literature[1] on static analysis of stack based VM instruction sets that show someone can statically analyze how valid a given instruction sequence is, and if it violates anything the host might consider to be incorrect, invalid, or undefined behavior[^3].
>
> Rust's MIR interpreter[2] predates WASM 1.0, and if it were to be retrofitted to support it, it would have to have MIR intrinsics due to the additional use of metadata and behavior it tries to diagnose. However, the only thing truly stopping Rust plugins from compiling to WASM is the lack of the reference types[3] and function-ref papers added to the WASM specification. It could most likely end up within the Rust compiler itself at some point as it would only be an ABI break, not an API break.
>
> That said, having spoken with Mara and @eddyb from github (who is effectively the author of the protocol for which proc-macros can speak with the rust compiler), the Rust compiler team is actually working to lock some of these things down, however the core compiler team is only a bit larger than the team working on MSVC.
>
> Regarding reflection, even if we specify it in such a way that it cannot do arbitrary things, as long as compilers have a mechanism to communicate with a process outside, anything is possible. Trying to design it to be as sandboxed as possible is, quite honestly, like trying to solve the piracy issue in game development.
>
> [1]: "Virtual Machines" *Iain D. Craig *ISBN-13: 978-1849969802
> [2]: https://github.com/rust-lang/miri
> [3]: https://github.com/WebAssembly/reference-types
>
> [^1]: Not to be confused with the hygenic macro syntax, proc-macros are compiled as a plugin against the Rust compiler. Hygenic macros do not suffer from this issue, as they only operate on the AST with a custom syntax.
>
> [^2]: In part based off of the work done on CloudABI, to the point that when WASI was announced some of the documentation was copied word for word, though the CloudABI people didn't make a fuss about it. WASI allows for things like file I/O and networking, however its specified in such a way that even these can be sandboxed by a host if desired.
>
> [^3]: Iain Craig details how both the JVM and CLR (at the time of writing in 2005, things have changed since then of course) allow for analysis of allowed (but undesired) behavior. However I believe to date, no one has taken advantage of the work detailed in the book and finding the book itself is in fact very difficult these days, looking at prices on Amazon and elsewhere.
>
> On Sat, May 15, 2021, at 16:55, JF Bastien via SG7 wrote:
> > I think I understand what you’re saying... and yes I agree that reflection should not do arbitrary stuff at compile time.
> >
> > That said, today’s compilers are already not implemented to recent this type of attack at all. You can exploit a compiler way easier than say a web browser. Reflection won’t open a Pandora box all of a sudden... but we should still design it in a way that’s bounded 🙂
> >
> >
> > On Sat, May 15, 2021 at 4:49 PM Herb Sutter <hsutter_at_[hidden]> wrote:
> >> I should tease apart two things:____
>
> >> __ __
>
> >> Yes, the general issue is the ability to link and run arbitrary libs at compile time. That’s the main point below, a concern we had that appears to be arising in the wild for languages that went down that path.____
>
> >> __ __
>
> >> But, secondarily, I thought it’s also related to the narrower issue of Trusting Trust attacks because Thompson’s initial approach required a specially-crafted compiler binary that already carried the malicious code, whereas the ability to execute arbitrary libraries at compile time (esp. malicious ones that can do introspection) could give a new vector to inject Trusting Trust attacks… the compiler can be totally pristine, but comes with a launchpad to let you provide the malicious code later. No?____
>
> >> __ __
>
> >> __ __
>
> >> __ __
>
> >>
>
> >> *From:* JF Bastien <cxx_at_[hidden]>
> >> *Sent:* Saturday, May 15, 2021 3:34 PM
> >> *To:* sg7_at_[hidden]
> >> *Cc:* Hana Dusíková <hanicka_at_[hidden]>; Chandler Carruth <chandlerc_at_[hidden]>; Herb Sutter <hsutter_at_[hidden]>
> >> *Subject:* Re: [SG7] Thompson Turing lecture____
> >>
>
> >> __ __
>
> >> It's not really the same issue: trusting trust is about the compiler changing the code it's compiling (including changing a compiler it's compiling to continue having this behavior), whereas the Rust thing is that macros can execute arbitrary Rust including networking code. The Rust problem is equivalent to putting arbitrary code in your makefile. It's something that you could sandbox and disallow (say, by running the compiler in a container). Whereas trusting trust is very hard to detect because the compiler's output binary is what's been compromised and you can't easily tell.____
>
> >> __ __
>
> >> On Sat, May 15, 2021 at 3:24 PM Herb Sutter via SG7 <sg7_at_[hidden]> wrote:____
>
> >>> Below, I emailed the “Trusting Trust” reference during our SG7 session on Circle in Prague, because SG7 was in the middle of discussing concerns about Circle’s approach of linking arbitrary libraries and executing them at compile time.____
>
> >>> ____
>
> >>> Since yesterday, I noticed the following tweets about Rust…____
>
> >>> ____
>
> >>> Tony “Abolish ICE” Arcieri 🦀 on Twitter: "Exfiltrating secrets with @rustlang macros: leveraging macro expansion in IDEs to exfiltrate secrets without compiling the code or even opening a file https://t.co/M2qhsfaLdX" / Twitter <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fbascule%2Fstatus%2F1393228285056741376&data=04%7C01%7Chsutter%40microsoft.com%7C961ce426a36a4eaf8e9908d917f185a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637567148365841167%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=G267zWwO9AX%2F3O0NRhQiGMIJJ8CD2A66ksYKok9as0I%3D&reserved=0>____
>
> >>> ____
>
> >>> Ralf (RPW) on Twitter: "„Open innocent_app in VSCode*, and the contents of your .ssh/id_rsa file will be sent over TCP to localhost:8080. You don't even need to open any files in the project!“ https://t.co/eKx2CWrirD" / Twitter <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fesizkur%2Fstatus%2F1393477018474459137&data=04%7C01%7Chsutter%40microsoft.com%7C961ce426a36a4eaf8e9908d917f185a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637567148365851162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=8WgNZXJKVCoFeUgU4lOGmrSRN%2FEJwDnIvy5BptZkOyo%3D&reserved=0>____
>
> >>> ____
>
> >>> Björk on Twitter: "@hankadusikova ... Wait, what? You can do compile-time I/O (networking) in Rust, or is this because of plugins executing arbitrary code? https://t.co/soA3bD9vT2" / Twitter <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2F__phantomderp%2Fstatus%2F1393553321177321473&data=04%7C01%7Chsutter%40microsoft.com%7C961ce426a36a4eaf8e9908d917f185a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637567148365861161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=JYRYlAxAlIj874btarG5yVdqa4WwFanyYIqCeJ%2FP9hU%3D&reserved=0>____
>
> >>> ____
>
> >>> David "Bear Feeder" Pollak🐈 on Twitter: "Oh crap! This will be 2021’s side channel attack… guess we have to run our compilers in containers with no network access…" / Twitter <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fdpp%2Fstatus%2F1393614418269802501&data=04%7C01%7Chsutter%40microsoft.com%7C961ce426a36a4eaf8e9908d917f185a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637567148365871158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=FN7TEy1emthwaJa4IX4NwgKa8LyGdcx1%2BtJ7tL34GK0%3D&reserved=0>____
>
> >>> ____
>
> >>> This sounds a lot like the same issue… is it?____
>
> >>> ____
>
> >>> (Ah, I just saw Hana’s tweet <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fhankadusikova%2Fstatus%2F1393532440120074243%3Fs%3D20&data=04%7C01%7Chsutter%40microsoft.com%7C961ce426a36a4eaf8e9908d917f185a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637567148365881150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=B5%2F3HwNOjk10s1UcxOJ7N6k0qpbCU1ldT4Qhthpxj%2BM%3D&reserved=0> before hitting Send – yup, sounds like it is the same issue, thank you Hana.)____
>
> >>> ____
>
> >>> ____
>
> >>> ____
>
> >>>
>
> >>> *From:* Herb Sutter
> >>> *Sent:* Thursday, February 13, 2020 7:59 AM
> >>> *To:* sg7_at_[hidden]
> >>> *Subject:* Thompson Turing lecture____
> >>>
>
> >>> ____
>
> >>> https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf <https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.cs.cmu.edu%2F~rdriley%2F487%2Fpapers%2FThompson_1984_ReflectionsonTrustingTrust.pdf&data=04%7C01%7Chsutter%40microsoft.com%7C961ce426a36a4eaf8e9908d917f185a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637567148365881150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=qWJ5TJJ1LacYSAnZqFU6fiulR6iyb5CNlMF1skn72Vo%3D&reserved=0>____
>
> >>> ____
>
> >>> As we we think about extensible compilers and JITs, this is a classic paper worth remembering about supply chain issues with just ordinary closed compilers.____
>
> >>> ____
>
> >>> Herb____
>
> >>> ____
>
> >>>
>
> >>> --
> >>> SG7 mailing list
> >>> SG7_at_[hidden]
> >>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C961ce426a36a4eaf8e9908d917f185a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637567148365891145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3ZKbFwRpHiQ3981DPNxSVWXndKEKo8Xj%2BB6FzcbLuj4%3D&reserved=0>____
> >>>
>
> > --
> > SG7 mailing list
> > SG7_at_[hidden] <mailto:SG7%40lists.isocpp.org>
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg7
> >
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
Received on 2021-05-16 02:39:35