"go-import" is great, we need "go-delete"

[Jeffery Carr]

The fact of the matter is that sometimes, I make really dumb mistakes. In the case of versioning things wrong, or making namespace errors, one needs to redo the namespace from scratch. This means we need some sort of way of purging namespace paths.

As far as I can tell, there is no way to do that yet. (?)

Please allow us to fix our mistakes!

Jeff

(just dumb things like "v0.2.0" being "v0.20" or "v2.0.0" alone is enough of a reason. but some repos like git2go are so broken the entire 250 git tags need to be purged. I mistakenly made go.wit.com/gui when it should have really been go.wit.com/gui/gui. There are endless reasons really)

[Dan Kortschak]

On Fri, 2024-12-27 at 15:42 -0800, Jeffery Carr wrote:
> The fact of the matter is that sometimes, I make really dumb
> mistakes. In the case of versioning things wrong, or making namespace
> errors, one needs to redo the namespace from scratch. This means we
> need some sort of way of purging namespace paths.
>
> As far as I can tell, there is no way to do that yet. (?)

You probably want https://go.dev/ref/mod#go-mod-file-retract

[Sean Liao]

The public module ecosystem is backed by a transparency log
https://go.dev/ref/mod#checksum-database
This doesn't allow you to reuse (change the definition of) any
published module + tag combination observed by the proxy
infrastructure.

- sean

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/4782f34c-ed2e-4639-9a3d-8683905dbe8dn%40googlegroups.com.

[Jeffery Carr]

"Retracted versions should remain available in version control repositories and on module proxies to ensure that builds that depend on them are not broken."

So, that is exactly what we don't want.

We need to remove all the copies at https://pkg.go.dev/ <namespace> so we can start over. That includes purging the module proxies. This already exists no doubt, but doesn't seem to be programmatically exposed to us as developers.

This is a plea to add that functionality, but I admit I don't know who to plea to.

jcarr

[Jeffery Carr]

On Friday, December 27, 2024 at 6:41:08 PM UTC-6 Sean Liao wrote:

The public module ecosystem is backed by a transparency log
https://go.dev/ref/mod#checksum-database
This doesn't allow you to reuse (change the definition of) any
published module + tag combination observed by the proxy
infrastructure.

Okay, that's neat, and not great, but fine. That problem can be ignored for now. I am correct in understanding this is like a blockchain then of md5sum like hashes? BUT NO CODE RIGHT?

In other words, the module proxies and pkg.go.dev don't get feed from the transparency log, the code can still be purged. Allowing go-delete to purge the code is what is still needed. Some other solution can be designed to sidestep the existing signed checksums. The permanent existence of those could be useful anyway. As long as it's only storing the checksum for the namespace@version.

So, again, please expose the functionality to delete things.

jcarr

 

[Sean Liao]

It does not exist, and is not possible due to the guarantees the module ecosystem wishes to provide. Any removal request you file only hides the generated documentation.

- sean

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/15c2db5e-1817-4163-bedf-272cefa7d623n%40googlegroups.com.

[Jeffery Carr]

On Friday, December 27, 2024 at 6:56:00 PM UTC-6 Jeffery Carr wrote:

On Friday, December 27, 2024 at 6:41:08 PM UTC-6 Sean Liao wrote:

The public module ecosystem is backed by a transparency log
https://go.dev/ref/mod#checksum-database
This doesn't allow you to reuse (change the definition of) any
published module + tag combination observed by the proxy
infrastructure.

If, what you are saying is true, and this is truly immutable like a blockchain, this this is bad. Whomever is working on it will want to immediately work on fixing that. I won't go into the nefarious reasons here. Let's just say it's going to have to be fixed.

Cryptographically signing this is bad.

[Jeffery Carr]

On Friday, December 27, 2024 at 6:58:18 PM UTC-6 Sean Liao wrote:

It does not exist, and is not possible due to the guarantees the module ecosystem wishes to provide. Any removal request you file only hides the generated documentation.

Well, I'm sure it exists. There are a million reasons, all bad, but I spent years fighting abuse at digital ocean. Anyway, it can all be purged. If the sum transparency log is immutable, I'll tell you right now that's going to be a massive problem.

jcarr

[Jeffery Carr]

Probably the transparency log should be broken up by hostname. The idea is fine, but the abuse vectors on things you can't control are terrible. So, make more than one transparency log. If you have one specifically for the golang.org namespace, then everything is perfect. It's when you mix the whole thing together so anyone, aka, bad actors, add things to it, it's totally a problem.

Also, then, for example in my namespace, go.wit.com for example, I can purge and recreate the transparency log if I have to. That would be a helpful solution to these problems!

happy hacking,

jcarr

[Dan Kortschak]

On Fri, 2024-12-27 at 17:01 -0800, Jeffery Carr wrote:
> I won't go into the nefarious reasons here. Let's just say it's going
> to have to be fixed.
>
> Cryptographically signing this is bad.

This kind of argument is unlikely to result in any change. If there is
something that you have knowledge of that would impact on the design,
file an issue (or if it is a security issue, send to
secu...@golang.org as described in go.dev/doc/security/policy).

[Jeffery Carr]

Okay, maybe.

I'm posting here on this forum about being dumb and making mistakes where I need a "go-delete" option.

I'm not sure it sounds like a good idea to email security professionals about why making a cryptographic blockchain available in real time everywhere that allows anyone to arbitrarily insert information into it permanently might be a bad idea! I think they probably would already know.

Anyway, if the transparency log can be be created by domain, then there can be a way to delete and recreate it. That would be helpful here.

We need "go-delete". Security is not important to us. There should be a balance between people that need security and people that don't need it.

jcarr

(maybe I will email that email address perhaps. thanks for the information)

[Jeffery Carr]

On Fri, Dec 27, 2024 at 7:30 PM Sean Liao <se...@liao.dev> wrote:

The zips (of your code) cached by the proxy can be removed.
The checksums held by the subdb cannot. The design for this is similar
to https://en.wikipedia.org/wiki/Certificate_Transparency not
blockchains which can hold arbitrary data.

It does hold arbitrary information.

Allowing you to change the contents of a given module+version is a non
goal as that opens the ecosystem up to supply chain attacks.

Cool for those people that need that, but if this means I can't "go-delete" and start over, kinda not helpful then.

If the transparency log was domain based (make a log for each hostname in the namespace) then this would be possible to more easily solve.

peace,

jcarr

[Christoph Berger]

> We need "go-delete". Security is not important to us. There should be a balance between people that need security and people that don't need it.

Security might not be important to you, but it is important for the clients of your code—for the users that won't expect that a module provider removes their repo or specific versions of a module, thus breaking all downstream projects.

Remember left-pad.

A per-domain go-delete would not be any better than a global go-delete. An immutable log guarantees, or at least greatly increases, supply chain security. Allowing anyone to rug-pull their libraries (or even just rug-pull specific versions) effectively prohibits any supply chain security. 

Consider using the GOPROXY or GONOPROXY environment variables during development to advise your Go toolchain to fetch specific or all modules directly rather than checking the proxy. Or use a Go workspace that can redirect any dependency to a local directory. This way, a new module or a new module version won't hit the Go proxy as long as they're only downloaded directly, bypassing the proxy. You can then make all kinds of dumb mistakes (frankly, we all do!) during development and fix them without a trace. 

Once you push a release version, clients may download the module normally, that is, through the proxy, and thus engrave the released version into the log.

[will....@gmail.com]

Jeffrey,

If modules worked like you suggested, a domain owner could be compromised, and the cryptographic module hashes for the domain could be changed to disrupt or infect dependencies. Version immutability prevents that: a module version is code + current import path ownership at the time the version is published. Authors can publish new versions to correct old ones, which the module/versioning designs took into account. You have to be careful about what Git version tags you publish. This is the deal the Go community made when it adopted the current module/versioning designs.

That being said, I see four paths you could take at this point:

If the package has never been downloaded by the Go proxy or a go tool, then change or delete the tag.

If the package has been downloaded by the Go proxy but not a go tool, then request that the package be removed from the proxy.

If the package has been downloaded by a go tool, then instruct the owner of every single one of them to manually delete the content from their local go tool cache.

If you have to, just make a v2 package in the same module, or a v2 module, and start from scratch.

Will

[Jeffery Carr]

On Sat, Jan 4, 2025 at 10:54 AM Christoph Berger <christoph...@gmail.com> wrote:

> We need "go-delete". Security is not important to us. There should be a balance between people that need security and people that don't need it.

Security might not be important to you, but it is important for the clients of your code

Can't we have both? 

How about a flag for 'go list' making the transaction log on sum.golang.org optional?

Or, how about just let users run their own:

sum.wit.com    # my own immutable transaction log.

Remember left-pad.

Ah, poor scripting languages. Since we are a compiler, it's not a fair fight is it?

We can 'git clone' anything into the namespace at compile time.

A per-domain go-delete would not be any better than a global go-delete.

It certainly is for me.

Asking to be able to delete errors and mistakes and start over is reasonable.

I made a namespace error that took 3 years to figure out that there was a better way. Now I can't fix it. Because what?

I assumed the proxy system was intended to make things elegant, fast and simple, not so much some magic super ultra security system that trumps PGP signed git repositories.

Happy hacking,

jcarr

As a funny aside, in the 80s movie Real Genius, they design a laser that ends up being for a space weapon. The transparency log might be the most reliable missile targeting system being that it's secure, works everywhere and is anonymous.

go get missle1.cia.gov/41.725556/-49.946944/killbill v0.0.2 (that's the location of the titanic)

Besides this silliness, I would think abuse for nefarious purposes would be high risk enough that you would want to push the log responsibility to the namespace owners and wipe your hands of the abuse problems.

[Jeffery Carr]

On Tuesday, January 7, 2025 at 8:25:46 PM UTC-6 will....@gmail.com wrote:

 

If the package has been downloaded by the Go proxy but not a go tool, then request that the package be removed from the proxy.

This is a landmark. I have to use system owned by microsoft to request the removal of my own GPL code.

The form makes it sound like it doesn't really remove the code from the proxies, just hides it from being visable on pkg.go.dev. If that is true, that's not a "delete and start over option" either.

If it was programatically available, that would be a start. It would be nice if someone with the authority to delete things from the module cache would expose that feature to us as developers so we can use it.

Thanks,

jcarr

[Ian Lance Taylor]

On Wed, Jan 8, 2025 at 4:19 PM Jeffery Carr <basil...@gmail.com> wrote:
>
> We can 'git clone' anything into the namespace at compile time.

But you can only do that if the git repository is still available.

> I assumed the proxy system was intended to make things elegant, fast and simple, not so much some magic super ultra security system that trumps PGP signed git repositories.

The proxy system was intended to make sure that builds that succeeded
in the past could be recreated in the future. See
https://go.dev/desidesign/25530-sumdbgn/25530-sumdb.

Yes, a consequence of a secure module proxy is that module names can't
be reused. Fortunately, the set of module names is unbounded, and the
only part that matters much for Go programs is the final path element.

Ian

[Christoph Berger]

How about a flag for 'go list' making the transaction log on sum.golang.org optional?

Or, how about just let users run their own:

sum.wit.com    # my own immutable transaction log.

I don't see how this helps with your initial request to delete modules from the proxy.

Ah, poor scripting languages. Since we are a compiler, it's not a fair fight is it?

The left-pad incident has absolutely nothing to do with how code is executed. Gophers can delete their repositories just like NodeJS devs can.

Asking to be able to delete errors and mistakes and start over is reasonable.

It is, and a solution exists: retract all versions of the module and start over. Inform the users of your module to switch over to the new namespace. (Give them time.)

If you actually want to hide errors and mistakes, retracting obviously doesn't help with this. Everyone makes mistakes (I do!), so why not leave them where they are and simply mark them as such.

We can 'git clone' anything into the namespace at compile time

Not if the repo owner has deleted it. Of course, you can vendor all direct and indirect dependencies into your repo, if you don't mind the added work and disk space consumption. But it's not an ideal solution.

some magic super ultra security system that trumps PGP signed git repositories.

It is, and it doesn't trump PGP signing but complement it. The Go proxy and its transparency log solve a completely different problem than commit signing. A signed repo can still be rug-pulled under your feet.

[Jeffery Carr]

On Wed, Jan 8, 2025 at 6:51 PM Ian Lance Taylor <ia...@golang.org> wrote:

Hello!

https://go.dev/desidesign/25530-sumdbgn/25530-sumdb.

Ironically, someone did 'go-delete' on that package so the document is missing ;)

Yes, a consequence of a secure module proxy is that module names can't
be reused. Fortunately, the set of module names is unbounded, and the
only part that matters much for Go programs is the final path element.

Just think about UNIX design over the years. We have slowly even changed things like /bin are now almost always linked to /usr/bin/. Namespace mistakes can take a long time to figure out.

As an aside, as a huge fan of automake and autoconf, I have made an autogenpb for generating Marshal(), Sort() and other functions from a protobuf file. It's an early tool, but I was guided by your and others work on auto* tools in the past so I thank you for that.

I'll start another thread about the transparency log now that I understand things more clearly due to everyones help here.

happy hacking,

jcarr

go install go.wit.com/apps/autogenpb@latest

[Dan Kortschak]

On Sun, 2025-01-12 at 19:45 -0600, Jeffery Carr wrote:
> > https://go.dev/desidesign/25530-sumdbgn/25530-sumdb.
> >
>
> Ironically, someone did 'go-delete' on that package so the document
> is missing ;)

This is the correct link: https://go.dev/design/25530-sumdb

[MKS Archive]

On Jan 4, 2025, at 11:53 AM, Christoph Berger <christoph...@gmail.com> wrote:

> We need "go-delete". Security is not important to us. There should be a balance between people that need security and people that don't need it.

Security might not be important to you, but it is important for the clients of your code—for the users that won't expect that a module provider removes their repo or specific versions of a module, thus breaking all downstream projects.

Well, it seems there are is at least one good reason for a go-delete — and a reason that is security-specific:

"The malicious package github.com/boltdb-go/bolt contains a backdoor that enables remote code execution, allowing a threat actor to control infected systems via a command and control (C2) server. After the malware was cached by the Go Module Mirror, which the Go CLI toolchain downloads from, the git tag was strategically altered on GitHub to remove traces of malware, hiding it from manual code review."

"As of this publication, the malicious package remains available on the Go Module Proxy. We have petitioned its removal from the module mirror and have also reported the threat actor’s GitHub repository and account, which were used to distribute the backdoored boltdb-go package."

From: https://socket.dev/blog/malicious-package-exploits-go-module-proxy-caching-for-persistence

#justfyi

-Mike

[Sean Liao]

a delete in the control of the module author would make it worse, as you can serve malicious modules for a while, then delete and hide it, making it unsuitable, unlike the current situation.

- sean

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/39A1062E-BF01-4B2A-80D9-3A4CD6139390%40gmail.com.

[Robert Engels]

Agreed. Better to have the Go tooling state “xxx module has been marked as a security risk” during compilation. 

On Feb 6, 2025, at 12:56 PM, 'Sean Liao' via golang-nuts <golan...@googlegroups.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAGabyPrKq%3DDSJGAsHpXOZ2d3NpQSQNzZ04amNeHY9m9fGeF0Eg%40mail.gmail.com.

[thepud...@gmail.com]

Hi Mike,

My understanding is that the folks operating the proxy have already removed that:

        "note that the module in question is no longer available from the module proxy"
        https://github.com/golang/go/issues/66653#issuecomment-2637831755

Best regards,
--thepudds

[Mike Schinkel]

> On Feb 6, 2025, at 1:55 PM, 'Sean Liao' via golang-nuts <golan...@googlegroups.com> wrote:
>
> a delete in the control of the module author would make it worse, as you can serve malicious modules for a while, then delete and hide it, making it unsuitable, unlike the current situation.
>

> - Sean


Yes. Immediately after emailing I realized someone would — rightfully, according to the wording I used — interpret my comment to mean I was suggesting a feature to allow the author to delete. That was not my intent.

I was instead just (secondarily) pointing out there is a need to delete existing packages, when they are malicious, and (primarily) making people aware of the specific vulnerability.

Sorry for my inelegant wording.

-Mike

[Axel Wagner]

Allowing not-the-author to delete a module, in general, is obviously also very bad.

There is already a process in place to request deletion a module from the proxy. See the last entry here: https://proxy.golang.org/

This thread isn't really connected to this news story, honestly. A manual process for deleting malicious modules already exists, an automated one available to the general public is inadvisable and one only available to the module author will do nothing, as they are almost generally malicious in this case.

The topic of this thread really only makes sense for accidentally published modules.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/C456F8A3-0E92-456B-9581-74DDBD19DC25%40newclarity.net.