Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code

legitsecurity.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code

#21

Post by isodev »

I’m so happy our entire operation moved to a self hosted VCS (Forgejo). Two years ago, we started the migration (including client repos) and not only we saved tones of money on GitHub subscriptions, our system is dramatically more performant for the 30-40 developers working with it every day.

We also banned the use of VSCode and any editor with integrated LLM features. Folks can use CLI based coding agents of course, but only in isolated containers with careful selection of sources made available to the agents.

Re: CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code

#22

Post by oncallthrow »

> I spent a long time thinking about this problem before this crazy idea struck me. If I create a dictionary of all letters and symbols in the alphabet, pre-generate their corresponding Camo URLs, embed this dictionary into the injected prompt,

Beautiful

Re: CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code

#23

Post by hansmayer »

isodev wrote: post #21

I’m so happy our entire operation moved to a self hosted VCS (Forgejo). Two years ago, we started the migration (including client repos) and not only we saved tones of money on GitHub subscriptions, our system is dramatically more performant for the 30-40 developers working with it every day. We also banned the use of VSCode and any editor with integrated LLM features. Folks can use CLI based coding agents of course,…

Just out of interest, what is your alternative IDE?

Re: CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code

#25

Post by aitchnyu »

isodev wrote: post #21

I’m so happy our entire operation moved to a self hosted VCS (Forgejo). Two years ago, we started the migration (including client repos) and not only we saved tones of money on GitHub subscriptions, our system is dramatically more performant for the 30-40 developers working with it every day. We also banned the use of VSCode and any editor with integrated LLM features. Folks can use CLI based coding agents of course,…

What do your CLIs connect to? To first-party OpenAI/Claude provider or AWS Bedrock?

Re: CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code

#26

Post by isodev »

aitchnyu wrote: post #25
isodev wrote: post #21

I’m so happy our entire operation moved to a self hosted VCS (Forgejo). Two years ago, we started the migration (including client repos) and not only we saved tones of money on GitHub subscriptions, our system is dramatically more performant for the 30-40 developers working with it every day. We also banned the use of VSCode and any editor with integrated LLM features. Folks can use CLI based coding agents of course,…

What do your CLIs connect to? To first-party OpenAI/Claude provider or AWS Bedrock?

Devs are free to choose, provided we can vet the model prover’s policy on training on prompts or user code. We’re also careful not to expose agents to documentation or test data that may be sensitive. It’s a trade off with convenience of course, but we believe that any information agents get access to should be a conscious opt-in. It will be cool if/when self hosting claude-like LLMs becomes pragmatic.

Re: CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code

#27

Post by isodev »

hansmayer wrote: post #23
isodev wrote: post #21

I’m so happy our entire operation moved to a self hosted VCS (Forgejo). Two years ago, we started the migration (including client repos) and not only we saved tones of money on GitHub subscriptions, our system is dramatically more performant for the 30-40 developers working with it every day. We also banned the use of VSCode and any editor with integrated LLM features. Folks can use CLI based coding agents of course,…

Just out of interest, what is your alternative IDE?

That depends a bit on the ecosystem too.

For editors: Zed recently added the disable_ai option, we have a couple of folks using more traditional options like Sublime, vim-based etc (that never had the kind of creepy telemetry we’re avoiding).

JetBrains tools are OK since their AI features are plugin based, their telemetry is also easy to disable. Xcode and Qt Creator are also in use.

Re: CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code

#28

Post by twisteriffic »

This exploit seems to be taking advantage of the slow token-at-a-time pattern of LLM conversations to ensure that the extracted data can be reconstructed in order? Seems as though returning the entire response as a single block could interfere with the timing enough to make reconstruction much more difficult.

Re: CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code

#29

Post by frumplestlatz »

isodev wrote: post #21

I’m so happy our entire operation moved to a self hosted VCS (Forgejo). Two years ago, we started the migration (including client repos) and not only we saved tones of money on GitHub subscriptions, our system is dramatically more performant for the 30-40 developers working with it every day. We also banned the use of VSCode and any editor with integrated LLM features. Folks can use CLI based coding agents of course,…

Banning VSCode — instead of the troublesome features/plug-ins — seems like a step too far. VSCode is the only IDE that supports a broad range of languages with poor support elsewhere, from Haskell to Lean 4 to F*.

I work at a major proprietary consumer product company, and even they don’t ban VSCode. We’re just responsible for not enabling the troublesome features.

Re: CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code

#30

Post by trenchpilgrim »

frumplestlatz wrote: post #29
isodev wrote: post #21

I’m so happy our entire operation moved to a self hosted VCS (Forgejo). Two years ago, we started the migration (including client repos) and not only we saved tones of money on GitHub subscriptions, our system is dramatically more performant for the 30-40 developers working with it every day. We also banned the use of VSCode and any editor with integrated LLM features. Folks can use CLI based coding agents of course,…

Banning VSCode — instead of the troublesome features/plug-ins — seems like a step too far. VSCode is the only IDE that supports a broad range of languages with poor support elsewhere, from Haskell to Lean 4 to F*. I work at a major proprietary consumer product company, and even they don’t ban VSCode. We’re just responsible for not enabling the troublesome features.

> VSCode is the only IDE that supports a broad range of languages with poor support elsewhere

I just checked Zed extensions and found the first two easily enough. The third I did not, since they don't seem to have a language server, just direct integrations for vim/emacs/vsc.

Post reply on HN