mastouille.fr est l'un des nombreux serveurs Mastodon indépendants que vous pouvez utiliser pour participer au fédiverse.
Mastouille est une instance Mastodon durable, ouverte, et hébergée en France.

Administré par :

Statistiques du serveur :

594
comptes actifs

#openbsd

37 messages33 participants7 messages aujourd’hui

#OpenBSD's acme-client(1) now supports the draft-ietf-acme-profiles specification, supported by certificate authorities like Let's Encrypt.

ietf.org/archive/id/draft-ietf

This allows for different "profiles" to be provided that can be selected by the user, such as "shortlived" TLS certificates.

sthen@ modified src/usr.sbin/acme-client/*: implement draft-ietf-acme-profiles for acme-client, ok florian

letsencrypt uses this to allow asking for a certificate with a specific TLS profile; see letsencrypt.org/docs/profiles/ for current options

note that with current timers, if you select the non-default "shortlived" profile, renewal will be done at each acme-client run. if this results in exceeding rate limits, adjust cronjobs, or don't do that. (this is being
looked at, but may possibly be too sensitive to change before release).

The issue with renewal timers was addressed in a subsequent commit by florian@:

florian@ modified src/usr.sbin/acme-client/revokeproc.c: Adapt renewal calculation for shortlived certificates.

If the lifetime is more than 10 days renew if less than 1/3 of the lifetime is left. Otherwise renew after 1/2 of the remaining lifetime.

Since we suggest to run the cronjob daily, this is capped at 3 days remaining lifetime to have the opportunity to run the cronjob at least twice.

Input & OK tb, sthen

Putting it in now because it gives buypass users 60 days of warnings instead of 30 that their certificate can't be renewed (pointed out by sthen).

A répondu dans un fil de discussion

@meluzzy

I bought a 9-year-old (at the time) #Thinkpad x200 in January 2019 "just for writing and stuff" and daily-drove it for years.

It still gets used occasionally and runs #OpenBSD very nicely.

This year, I'm planning on "splurging" on an actually-new laptop: an HP Stream 11, provided there's a nice discount on it sometime next month or the one after.

Who knows how long that one will last me. XD

My currently-used machines (not counting work) are from 2019, 2016, and 2010.

All running strong. :D

A répondu dans un fil de discussion

@ireneista @existentialcomics

I honestly greatly prefer #OpenBSD's attitude of, "This is our system, we made it the way we want it, if you don't like it, go eff yourself or run Linux or something, whatever" over #systemd's "Here's a few million lines of source code, you don't *wink* have to *wink* use it of course, we'll only pester the ever living fork out of ever major distro to use it and wage psychological warfare on Debian maintainers until they comply. *wink* *uwu*"

Oh and of course, if you complain about it, we'll just say "Oh, but SYSVinit sucked so hard, what is even wrong with you, you actually want to maintain SHELL SCRIPTS?!?" as if we're just an init system anymore, lol

Honestly, the level of psyops from these people should inspire the republicans.

#OpenBSD's i386/amd64 bootloader has long had a built-in command "mach[ine] mem[ory]" to print the memory map, and was often useful to include in bug reports, etc.

man.openbsd.org/man8/amd64/boo

This command also historically supported the ability to modify the memory map obtained from the BIOS to artificially constrain system memory for debugging.

boot> mach mem =64M

It was also occasionally used by developers/users to workaround broken configurations (removing a memory range clobbered by the BIOS/devices at runtime, etc), and could even be added to boot.conf(5).

Unfortunately, modifying the memory map has not worked at all on UEFI machines... until today! :flan_hacker:​ *

marc.info/?l=openbsd-cvs&m=175

That said, please don't do this. :flan_peek:

man.openbsd.orgboot(8) - OpenBSD manual pages