I’ve settled on this idea as a Python developer. I don’t care if I have long names. I care about:

• understanding what it is merely by reading its name
• ability to sort lexically and items be returned in a manner I find satisfying
• uniform string structure, typically delimited by hyphen or underscore (I don’t care which, most of the time)

Names can be long. spark_write_operation_status_failfast is leagues better than some like write_op_stat

As I’ve grown older, I’ve realized that I care a lot less about whether I own the device or the ISP. I’ll happily root the fucking thing. What are they going to do, send me to a competitor? I have 3 different networks I can connect from at any moment (including hotspots), so I’m not worried about a minor lapse due to ISP temper tantrums.

I will tell them casually too. I don’t want their support. I pay for internet access, it’s their problem if they try to make my access conditional beyond that.

One of these days I’ll figure out why NetSuiteERPs SuiteQL API fails with 4xx when you start the day by querying it at current_time © for all the data updated from c-1day to c-1sec.

+ QubesOS >, if you’re into that kinky stuff.

Gentoo > Arch > Elementary

Sounds like the solution would be a public code sharing platform that specifically bans AI generated code. Then, at least, we’re moving in the right direction. Do any alts to GitHub provide such a rule?

It doesn’t need to be perfect nor catch every offender. No need for magic AI-coded detection sauce. If it just detected slop, human or otherwise, and obviously AI-written code, with a reporting mechanism for user-driven monitoring, that could be a good start

But, should we worry about it being a source for AI companies to scrape? How should we deter that?

I’ve learned to wear brown pants so it’s not as bad.

*Bot propaganda?

You clearly haven’t tried using one of there services APIs.

My work processes PDFs from government sites, filling them out for end users automatically. Would be cool if the API could do this somehow. Parse fields, and let you put text into them.

Gitea Actions, as well.

These might be apples and oranges, but how does NextCloud compare to Seafile?

I was curious and, yeah, it seems like docker hub not requiring signature means many popular publishers don’t bother to sign. But that’s not to say it can’t be done. For example: https://github.com/sigstore/cosign

Today, cosign has been tested and works against […] Docker Hub

Again we’re talking past each other. I’m sure those results are available and I’m aware docker doesn’t verify signatures automatically, but I’m asking how that necessarily makes docker insecure in spite of best practices being implemented. It’s about pinning yourself to trusted digests and having a verification process (like time) before updates. Why would you need authorship verification in that case? If there’s a good answer to that, I’d consider alternatives too. I’m just saying I don’t think it’s inherently insecure over this, and at face value It boils back down to the classic: don’t download untrusted software.

You’re making big claims on security here, like “cannot be done,” and each time you do I feel like we’re talking past each other a bit. I never claimed you can verify that the person who pushed the container had access to a private key file. I claimed you can verify the security of a container, specifically by auditing it and reviewing the publisher’s online presence. Best practices. Don’t upgrade right away, and pin digests to those which can be trusted.

When you pin a digest, you’re not going to get a container some malicious agent force pushed after the fact. You pinned the download to an immutable digest, so hot-swapping the container is out the window. What, as I understand, you’re concerned with is the scenario that a malicious actor (1) compromised the registry login beforehand, (2) you pinned the digest after hand, and (3) the attack is unnoticed by you and everyone else.

I’m trying to figure out under what conditions this would actually occur, and thus justifies the claim that docker pull is insecure. In a work setting, I only see this being an issue if the process to test/upgrade existing ones is already an insecure process. Can you help me understand why I should believe that, even with best practices in place, Dockers own insecurities are unacceptable? Docker is used everywhere and I’m reluctant to believe everyone just doesn’t care about an unmanageable attack vector.

You’re talking about authorship. Sure. But if you verify the container yourself as secure and pin the digest, what’s the issue?

What are you talking about, “yeah that’s the insecurity I’m talking about.”

I didn’t mention an insecurity and neither have you. Would you mind being a little more clear than “Docker pull is insecure?”

Frankly, I was expressing confidence in dockers security. It goes without saying though, any user can do insecure things like download from untrusted sources. That’s not dockers problem though, it’s the users.

Edit: I see now that you added “it’s the download that’s not verified.” Integrity is verified, so I assume you mean authorship (via signing)? I guess you’re saying that, if admin credentials are stolen from a container publisher and the thief force pushes malicious code into the registry under a pre-existing tag—then you would be exposed to that?

Even in that case, though, a digest cannot be overwritten. Tags can. So you’d just pin the digest to avoid this one attack vector?

You can verify the checksum to ensure the contents pulled are exactly the same as what was published. You can also use a private container registry.

How exactly would docker pull be any more insecure than something like pip install? Or, really anything… Let’s go with your preferred alternative, how are you going to get it on your machine in a more secure way than docker provides?

Docker uses TLS with registries, layers and manifests have cryptographic digests, checksums, and you can verify the publisher yourself. Push it into your own registry if you want, or just don’t use latest.

Docker is a security risk? … excuse me, what? Can’t you just, idunno, secure the environment that docker runs in? Use rootless images? Use immutable images?

And, are you asking for something that runs on bare metal? Couldn’t you just install the ISO that the dockerfile uses, then convert the dockerfile logic to an sh script?

deleted by creator