codesniperjoe

Warning:

Do not go to this site with enabled javascript! They spam your uplink DNS provider with thousands of uniq, uncachable (fingerprinting?) 'test' dns keys without your consent, to identify & track the DNS service you are using!

Take a look at your DNS outbound log yourself!

Projects Console screen reader infrastructure Vessel - Integrated Application Containers for FreeBSD Enable the NFS server to run in a vnet prison Pytest support for the FreeBSD testing framework Userland Base System OpenSSH Update Kernel Enabling Snapshots on Filesystems Using Journaled Soft Updates Wireless updates Netlink on FreeBSD Adding basic CTF support to ddb Architectures CheriBSD 22.12 release FreeBSD/riscv64 Improvements go on FreeBSD riscv64 FreeBSD/ARM64 on Xen Cloud FreeBSD on Microsoft HyperV and Azure FreeBSD as a Tier 1 cloud-init Platform OpenStack on FreeBSD Documentation Documentation Engineering Team FreeBSD Presentations and Papers Ports FreshPorts - help wanted PortsDB: Program that imports the ports tree into an SQLite database KDE on FreeBSD Xfce on FreeBSD Pantheon desktop on FreeBSD Budgie desktop on FreeBSD GCC on FreeBSD Another milestone for biology ports Third Party Projects Containers and FreeBSD: Pot, Potluck and Potman

TLDR: Avoid it if you can!

TDLR: How You Respond to Security Researchers Says Everything ... [ About Your Business State ].

The compiler (go) is part of a static read-only (compressed/in-memory) RootFS. Build on a air-gap build server, touching only signed/verified/reviewed code from git-offline mirror snaps. Go has no libs, all static. The resulting runtime only binaries are totally uniq/randomized and dependency free, straight from (signed) source code.

Yes, the base idea is not that new. I store since years every GO based application I use as small (few kb) source code tree checkout only, no binary at all. At runtime the wrapper compiles a randomized individual one-time-temporary-uniq binary via garble [0].

[0] https://github.com/burrowers/garble

For this new feature you pay indeed with the need for r/w and executable tmpfs/overlay somewhere.

This does not replace classic ASLR: OpenBSD 5.7 activated position-independent static binaries (Static-PIE) by default.

https://en.wikipedia.org/wiki/Address_space_layout_randomiza...

Plain, simple and effective as always! The highly complex 'black magic' is 'sort --random' and (re-)link it all again. :)

Makefile.relink: cc -o sshd `echo ${OBJS} | tr ' ' '\n' | sort -R` ${LDADD} ./sshd -V && install -o root -g wheel -m ${BINMODE} sshd /usr/sbin/sshd

https://github.com/openbsd/src/commit/898412097f87ba70d4012f...

Finally!

At least, someone finally understands that static, fully predictable, reproduce-able-builds are only an convenience feature for the attacker side.

In general I would tend to agree, but have lately took a look at the gh dependencies this tool draws in today? [0]

This is not a (classic) unix cli tool, as it was some month before. Do you think anyone will be ever able to make a codereview? Like done for git [1]?

[0] https://github.com/cli/cli/blob/trunk/go.mod

[1] https://x41-dsec.de/security/research/news/2023/01/17/git-se...

On the other side: a simple and easy to understand plaintext curl one-liner.

We should really pin a daily reminder about the unfixable SSL truststore dumpster fire situation (every day a different one) to the top of YC!

Netflix contributes. Real Code. Rock stable. High quality. For so many years. So its not only the Free-Beer-License for them. I have never seen a single commit comming back from others, who build the most (financial) successfull trillion dollar bussines on top of FreeBSD, but comming back again and again, to (hard-)fork.

FreeBSD Hammer2 [r/o][pending]

Lots of work will end up (as often) in the ports section, if nobody has a strong point why it is usefull to maintain it in base.

Users/use-cases feedback are welcome.

https://reviews.freebsd.org/D37354 https://github.com/freebsd/freebsd-src/pulls

If google is on the way to fix this, a look at the resources on (EVERYONES LOCAL!) not de-duplicated $GOMODCACHE would be very welcome too!

(At least from an enviromental perspective.)

Easy to verify, get a report [1]: go install paepcke.de/fsdd/cmd/fsdd@latest && cd $GOMODCACHE && fsdd .

[1] Warning: Apple user with fixed restricted & expensive nvme space maybe very upset. Easy fixable via fsdd . --hard-link.

If you need a local & offline first tool to log/track/archive changes from all kind of git repos yourself, from:

* github.com * sourcehut (sr.ht) * gitlab.com * codeberg.org * ...

published ssh keys & changes, to verify (offline) ssh signed commits, verify, encrypt mails, exchchange secure data (age-enc).

You can use this app:

[] https://github.com/paepckehh/gitkeys

If you want your own repos public keys tracked / monitored / archived, just leave a star:

[] https://github.com/paepckehh/keys

TLDR: gps tracker with backup battery and activated sim card found in sealed car ECU (BTO from china, to save some pennies, in a high-security-custom build car)

Thank you! That is a quick (helpful) fix!

Beside of checks for the integrity of SelfSigned Certificates, I do not used this function directly.

My assumption about the TLS impact was based on the fact that [Certificate.Verify] uses internally [Certificate.buildChains] who calls [Certificate.CheckSignatureFrom], who has only the direct parents IsCA status, but not the full picture of the full path (and ignores it at the end, when missing on the root-Anchor)!?

And yes, in general, the max pathLen helps only to restict the impact of a specific (delegated) subCA compromise, not for a full root CA key leak. But I expect to see a well prepared narrative about a (revokeable) SubCA as most likely response, to protect the Root-Anchor itself. (What a happy co-incidence that the most Root-Anchors do not declare the planned SubCA strategy via maxPathlen upfront.)

One example, the started (and then stuck) net/ip to net/netip migration?

The tailscale netip package is great (as external pkg), but without commit to a full migration plan, just sprinkle here and there some (half/done/slow/wired/bridge) interfaces leads anyone, who tried to migrate, stuck as well. Some all ready started to migrate back ...

> TLS handshakes now return a CertificateVerificationError if they fail because of, well, certificate verification.

... as long the crypto/x509 CheckSignatureFrom ignores the pathlen contraint (the /ONLY/ way of an CA Owner pin down a delegated SubCA usage/raw-key-abuse!) im not sure that CertifictionVerification does what a high-level api user expects!?

Go is great. But if you look close enough, go also has some dark corners.

The reason the biggest parts of go/crypto is well designed, good readable code, is mostly the work of one person (the author).

> Finally, reviewing the BoringCrypto integration by Russ.

Do you think there is a rollback/cleanup possible of current boring/fips <enter most diplomatic/nice phrase here> situation?

(eg. push it back into a seperate stash, guarded by a fixed build-time compiler directive?)

Maphash is an (non-cryptographic-secure) hash function, like CRC32 / CRC64 / XXH3-64 and others, so it turns data in an (almost) uniq uint64.

The main difference is, it is an hardware accelerated & optimized compiler function, now exposed via the new maphash package in stdlib.

And it is fast. Faster than the former performance leader xxh3(avx2/avx512).

Try maphash yourself (example data dedupliction) https://news.ycombinator.com/item?id=34091206

Hi, just discovered that the (sometimes excessive large) golang mod disk cache is - in opposite to the compiler cache - not (yet) properly deduplicated.

Try yourself: Made a little hack/tool to deduplicate data via hardlinks (unix/i-node-filesystems tested only, not windows yet).

https://github.com/paepckehh/fsdd

(less than 1kLOC, 100% golang stdlib, no external deps)

  go install paepcke.de/fsdd/cmd/fsdd@latest

  cd $GOMODCACHE && fsdd --hard-link .

  FSDD [start] [/usr/store/gomod][hash:MAPHASH]

  FSDD [_done] [time: 39.000221ms]

  FSDD [stats] [files:13329] [inode(s): 8680] [sym.valid: 0] [sym.invalid: 0] [data blocks: 277.1 Mbytes]

  FSDD [_info] [new deduplication savings][inode(s): 4649] [data blocks: 66.9 Mbytes]

If you can reproduce and has it shows no downsides (remove/add should auto-dereference) it should be part of src/cmd/go/internal/mod* pack?

If you can confirm/field test, please report back! I would love to write a quick stdlib/proposal.

At golang scale, it could make a real resource / enviromental dent!

It least for me, it cut my disk cache in half and reduced vfs fs mem-cache required as well, so should scale even on deduplicated fs like zfs/btrfs. Made my batch builds fast and snappy again!

Michael (edit:first-post-ever-style-fixes)