Go is still not good | Thomas Habets

https://blog.habets.se/2025/07/Go-is-still-not-good.html

#golang

Now the fantastic @filippo gives us "The Go Cryptography State of the Union" here at GopherCon 2025 #gopherCon #golang

Now the fantastic @filippo gives us "The Go Cryptography State of the Union" here at GopherCon 2025 #gopherCon #golang

Implementing Forth in Go and C - Eli Bendersky's website

https://eli.thegreenplace.net/2025/implementing-forth-in-go-and-c/

#forth #golang #c

#ESETResearch has discovered the first known AI-powered ransomware, which we named #PromptLock. The PromptLock malware uses the gpt-oss:20b model from OpenAI locally via the Ollama API to generate malicious Lua scripts on the fly, which it then executes.
PromptLock leverages Lua scripts generated from hard-coded prompts to enumerate the local filesystem, inspect target files, exfiltrate selected data, and perform encryption. These Lua scripts are cross-platform compatible, functioning on #Windows, #Linux, and #macOS.
Based on the detected user files, the malware may exfiltrate data, encrypt it, or potentially destroy it. Although the destruction functionality appears to be not yet implemented. #Bitcoin address used in the prompt appears to belong to Bitcoin creator https://en.wikipedia.org/wiki/Satoshi_Nakamoto
For its file encryption mechanism, the PromptLock ransomware utilizes the SPECK 128-bit encryption algorithm.
Although multiple indicators suggest the sample is a proof-of-concept (PoC) or work-in-progress rather than fully operational malware deployed in the wild, we believe it is our responsibility to inform the cybersecurity community about such developments.
The PromptLock ransomware is written in #Golang, and we have identified both Windows and Linux variants uploaded to VirusTotal. IoCs:
🚨 Filecoder.PromptLock.A
📄 24BF7B72F54AA5B93C6681B4F69E579A47D7C102
AD223FE2BB4563446AEE5227357BBFDC8ADA3797
BB8FB75285BCD151132A3287F2786D4D91DA58B8
F3F4C40C344695388E10CBF29DDB18EF3B61F7EF
639DBC9B365096D6347142FCAE64725BD9F73270
161CDCDB46FB8A348AEC609A86FF5823752065D2

#ESETResearch has discovered the first known AI-powered ransomware, which we named #PromptLock. The PromptLock malware uses the gpt-oss:20b model from OpenAI locally via the Ollama API to generate malicious Lua scripts on the fly, which it then executes.
PromptLock leverages Lua scripts generated from hard-coded prompts to enumerate the local filesystem, inspect target files, exfiltrate selected data, and perform encryption. These Lua scripts are cross-platform compatible, functioning on #Windows, #Linux, and #macOS.
Based on the detected user files, the malware may exfiltrate data, encrypt it, or potentially destroy it. Although the destruction functionality appears to be not yet implemented. #Bitcoin address used in the prompt appears to belong to Bitcoin creator https://en.wikipedia.org/wiki/Satoshi_Nakamoto
For its file encryption mechanism, the PromptLock ransomware utilizes the SPECK 128-bit encryption algorithm.
Although multiple indicators suggest the sample is a proof-of-concept (PoC) or work-in-progress rather than fully operational malware deployed in the wild, we believe it is our responsibility to inform the cybersecurity community about such developments.
The PromptLock ransomware is written in #Golang, and we have identified both Windows and Linux variants uploaded to VirusTotal. IoCs:
🚨 Filecoder.PromptLock.A
📄 24BF7B72F54AA5B93C6681B4F69E579A47D7C102
AD223FE2BB4563446AEE5227357BBFDC8ADA3797
BB8FB75285BCD151132A3287F2786D4D91DA58B8
F3F4C40C344695388E10CBF29DDB18EF3B61F7EF
639DBC9B365096D6347142FCAE64725BD9F73270
161CDCDB46FB8A348AEC609A86FF5823752065D2

Also, perhaps somebody has references about this #GoLang convention, and its deeper reasoning? #go

I'm really puzzled at some #GoLang "conventions":
https://github.com/mholt/archives/issues/3#issuecomment-3212123684

In this issue, a smaller-than-produced-value type is exposed on a factory API: this would make sense if coding defensively, to reduce the API surface, but not here, IMO.

Forcing consumers to do runtime upcasting because of a convention feels wrong, but I'm perhaps missing part of the picture somewhere.

To me, making something "fail at compile time, when wrong" is a massive value proposition for a compiled language.

"If you must read the rest of this document to understand the behavior of your program, you are being too clever.

Don't be clever."

https://go.dev/ref/mem

#golang

"If you must read the rest of this document to understand the behavior of your program, you are being too clever.

Don't be clever."

https://go.dev/ref/mem

#golang

zen80 update: improved tests

*** Apart from the already substantial unit tests, we now have two additional and rather stringent tests:***

1. This test loads the ZX Spectrum 128 ROMs (0 and 1) and run that machine's initialisation process. Then it shows a statistical analysis of the instruction coverage that's been executed during rom initialisation. (total percentage of different opcodes executed for each instruction group)

2. The second big test implements traps as barebones CP/M shims, loads ZEXDOC.COM and runs its extensive stress test (this can be long).

Work is ongoing to support ZEXALL.COM as well, an even more stringent version of zexdoc that also tests undocumented registers and quirks of the Z80, one of the hardest tests known. This will be next, after I'm certain that this passes all ZEXDOC tests without a hitch. So far so good!

#zen80 #emulator#ZXSpectrum#Speccy#Spectrum #golang #foss #z80

zen80 update: improved tests

*** Apart from the already substantial unit tests, we now have two additional and rather stringent tests:***

1. This test loads the ZX Spectrum 128 ROMs (0 and 1) and run that machine's initialisation process. Then it shows a statistical analysis of the instruction coverage that's been executed during rom initialisation. (total percentage of different opcodes executed for each instruction group)

2. The second big test implements traps as barebones CP/M shims, loads ZEXDOC.COM and runs its extensive stress test (this can be long).

Work is ongoing to support ZEXALL.COM as well, an even more stringent version of zexdoc that also tests undocumented registers and quirks of the Z80, one of the hardest tests known. This will be next, after I'm certain that this passes all ZEXDOC tests without a hitch. So far so good!

#zen80 #emulator#ZXSpectrum#Speccy#Spectrum #golang #foss #z80

zen80 emulator UPDATE:

Published a detailed implementation status report and instruction set coverage for our Z80 emulator in Go.

https://github.com/ha1tch/zen80/blob/main/COVERAGE.md

All documented Z80 instructions work correctly. Most undocumented features implemented, with some known gaps: IXH/IXL register access, simplified I/O flags, and a few edge cases in block instructions.

The emulator runs most Z80 software perfectly - it's only software relying on obscure undocumented behaviours that might have issues.
Full instruction-by-instruction breakdown now in the repo, with every opcode mapped to its implementation function and realistic status markers.

#z80 #emulation #retrocomputing #golang #zen80

I rewrote the #regal e2e tests the other day. Tests that exec the actual binary and verify the results. Can’t get more e2e than that! But tests were verbose, procedural and contained way too many lines of scaffolding. The new e2e test suite uses a functional DSL I wrote for the purpose, is declarative, contains not scaffolding, and is less than half the number of lines of code. One thing it isn’t however is “idiomatic #golang”. But I was already banned from that heaven, so no harm done 😎

https://github.com/StyraInc/regal/pull/1640/files

From the #golang docs on naming packages. Which is good advice of course. But whoever named Go stdlib packages like "path", "list", "fs", "maps", "flag", "hash", "strings", "iter", "url", "mail", "user", "metrics", "scanner", "sort", "slices", "template", "unique" was clearly not having any of that.