Live data from Hacker News

GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

theinsaneapp.com

91–100 of 161 posts

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#91
post #83

Earlier quoted context omitted.

I would assume github could supercede your license by putting its own claim to your code in the TOS. I doubt they have done that, but just pointing it out.

I don’t think that’s possible, as long as you don’t actively accept that. Nobody can claim your copyright without your approval. It would be also the end of GitHub, as most users probably won’t accept such terms.

I dont disagree with users not accepting the terms, just pointing out that license text doesn't trump everything.

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#93
post #25

Earlier quoted context omitted.

An IDE or other tools will generate correct boilerplate code. Seems a gripe from someone that prefers hidden magical code that setups code behind their back. The evil is that someone trained an AI on random text , not even with some AST, so you have garbage in so no surprise you get garbage out. A true AI would understand that "the dev wants trough find all lines of text in a file that have this property", the AI jus…

The problem with boilerplate code is, that it is mostly generated once (by the ide) and then slightly modified. More like a template. In the end you get a lot of meaningless code (the generated code), with some meaningful parts inside. But you can’t see anymore what was generated and what was added manually without deep analysis of the commit log. It is much better to generate code on the fly during build, so it does…

Code generated by magic is worse in my experience, with non-magic code you put a breakpoint where the project starts and you can run step trough it line by line, function by function and it makes sense. What I hate are magic frameworks that are terrible at reporting the issues, say in angular1 you have some bindings and soemtimes they don't trigger , you can't debug the magic strings of the templates in the debugger to see what is happening (it could be a typo but because is all Google dev magic it won't warn you about it).

I hope we are talking about same things, like you dislike creating classes and function explicitly and prefer adding a comment or some templating system that generates a ton of obscure code behind the scenes.

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#94
post #57

Earlier quoted context omitted.

Do you think only experts should be programming? I'm an amateur programmer, and I think copilot could help me a lot with unimportant things, as you said - I even tried to install it but I'm not on some list. I can read code, and have built a few programs - I've hired around 30 different programmers in my life, and the vast majority clearly are copy-pasters-adapters. The way I see it, that happens because programming…

I think the argument is that an amateur with copilot is going to stay an amateur longer than someone without copilot while simultaneously only helping them create something no one--including them--should rely on: it teaches the wrong habits and helps with the wrong problem.

This is good way to put it.

Another way: copilot is a crutch. It may help you move about but if you get too comfortable with it you are never going to learn to run.

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#95
post #87
post #83

Earlier quoted context omitted.

I don’t think that’s possible, as long as you don’t actively accept that. Nobody can claim your copyright without your approval. It would be also the end of GitHub, as most users probably won’t accept such terms.

According to many people familiar with the legal aspect training on code constitutes fair use, so can't be prevented by any kind of license.

Training, exactly. But the trained person or AI is not allowed to reproduce your exact code. But Copilot seems to do that from time to time.

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#96
post #25

Earlier quoted context omitted.

The problem with boilerplate code is, that it is mostly generated once (by the ide) and then slightly modified. More like a template. In the end you get a lot of meaningless code (the generated code), with some meaningful parts inside. But you can’t see anymore what was generated and what was added manually without deep analysis of the commit log. It is much better to generate code on the fly during build, so it does…

Code generated by magic is worse in my experience, with non-magic code you put a breakpoint where the project starts and you can run step trough it line by line, function by function and it makes sense. What I hate are magic frameworks that are terrible at reporting the issues, say in angular1 you have some bindings and soemtimes they don't trigger , you can't debug the magic strings of the templates in the debugger…

Generated code doesn't have to be magical. The generated code should off course be reviewed by a person from time to time. It must be debuggable and readable/understandable too. Otherwise it doesn't make any sense.

A good example for generated code are typed clients for an OpenAPI interface. Instead of writing a REST client on your own based on a spec, you generate it. And if something isn't right in the first place, don't edit the generated code, fix/configure the generator instead!

Or database models. Either generate the database from the models or the models from the database.

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#97
post #44

Earlier quoted context omitted.

You would have to not host your code publicly either, right?

Merely hosting your code publicly seems like it wouldn't give GitHub the right to train AI models on it. You could even say it's against your terms of use. And to do it, they would have to go out of their way to find your repo on the web and clone it—unlikely. My impression (NOT A LAWYER) is that by hosting your code in a public repo on GitHub, you agree to their terms and give them the right to "read" your code incl…

I wish it were easier to convince projects I like and want to help migrate for the same reason. Committing to their repos does not put me in the clear--including mere mirrors.

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#98
post #20

Earlier quoted context omitted.

(I have been professionally programming Java backends for the past 16 years). Java is not the culprit here. I think it is something that happened on the way that has something to do with J2EE and patterns craze we had a decade ago or two ago. It doesn't help that frameworks like Spring and their documentation go out of their way to propagate these boilerplate-heavy patters. Copying these lazy patterns is shortest, ea…

>Java is not the culprit here. It definitely is the culprit. They didn't even want to add `var` to the language until recently, and let's not even go to the anonymous class vs lambdas retardation. These are just the things that they eventually buckled on, but Java is extremely boilerplatey - the bad patterns and XML crap got invented to deal with that problem. DDD and onion are another issue, mostly coming out of the…

The TDD movement came from smalltalk programmers (not that I think it has anything to do with smalltalk, just the programmers came from there). In my experience it was in Ruby and javascript code where I have seen the most inane micro(nano?)-unit tests. Some of this was partly because the unit tests were testing what a static typechecker could verify automatically (at the cost of a little verbosity).

I don't see how you figured there is a relationship between DDD and "make everything unit testable". DDD is about high level architecture. It's at the opposite end of the spectrum.

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#99
post #2

I thought this should have been expected. Security starts with deep understanding. Some standards and practices can help avoid some types of problems, and some are even rather effective (like airgapping your systems), but there isn't any way to assure security in general other than truly understand what you are doing. ** I feel like Copilot is the wrong direction to optimize development. This is mostly going to help…

> Security starts with deep understanding.

I wonder if the way we are approaching it is wrong. We are basically putting text though a deep learning black box. The model might have learned some abstractions, but all in all it is just playing word games and trying to guess the most likely continuation of a string. Maybe we should go into the other direction and base such an AI on a really massive ontology. Instead of unstructured strings, put highly structured facts into the model.

For example, just like in Copilot you'd start with:

    def login_user(username, password):
But the ontology would also know things like:

- This is a web application and this function is going to be called after submitting a form

- Security specialist Bob says you should always hash your passwords

- Specialist Anne says you should use bcrypt

- Tom says Anne is 95% trustworthy

... and thousands of facts more. And then it would take them all into consideration, build a represenation of the problem you are trying to solve, find a strategy, and only in the end generate code.

I have a feeling that there was a qualitiative leap going from simple neural networks and multivariate methods to "deep learning" and modern machine learning, and that this is mainly driven by scale and available computing power. Now what if we try the same thing for ontologies, expert systems, and triple store databases? I think the difference will be between some AI parroting what it read on Wikipedia (direct speach), and a smarter AI being able to reason about what it read on Wikipedia (indirect speach).

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#100

Earlier quoted context omitted.

>Java is not the culprit here. It definitely is the culprit. They didn't even want to add `var` to the language until recently, and let's not even go to the anonymous class vs lambdas retardation. These are just the things that they eventually buckled on, but Java is extremely boilerplatey - the bad patterns and XML crap got invented to deal with that problem. DDD and onion are another issue, mostly coming out of the…

The TDD movement came from smalltalk programmers (not that I think it has anything to do with smalltalk, just the programmers came from there). In my experience it was in Ruby and javascript code where I have seen the most inane micro(nano?)-unit tests. Some of this was partly because the unit tests were testing what a static typechecker could verify automatically (at the cost of a little verbosity). I don't see how…

Also, smalltalkers didn't mean the same thing by "unit". What would be called unit tests in one context may mostly be considered integration tests in another.

I agree, the crazy mock- and stub-heavy unmaintainable micro unit testing thing seems to have been an innovation that came out of the Ruby scene.

Post reply on HN