Page MenuHomeFreeBSD

Remove cap_random(3).
ClosedPublic

Authored by markj on Jul 23 2019, 1:58 AM.
Tags
None
Referenced Files
F81623136: D21033.diff
Fri, Apr 19, 3:37 AM
Unknown Object (File)
Wed, Apr 17, 8:45 AM
Unknown Object (File)
Wed, Apr 17, 8:44 AM
Unknown Object (File)
Wed, Apr 17, 8:44 AM
Unknown Object (File)
Wed, Apr 17, 8:44 AM
Unknown Object (File)
Mon, Apr 15, 1:21 PM
Unknown Object (File)
Sat, Mar 30, 7:01 PM
Unknown Object (File)
Jan 11 2024, 11:13 AM

Details

Summary

It was added before we got the getrandom(2) system call, which can be
used in capability mode. cap_random(3) has no consumers in the base
system and is obsolete, so let's get rid of it.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 25493
Build 24112: arc lint + arc unit

Event Timeline

This revision is now accepted and ready to land.Jul 23 2019, 2:20 AM
delphij requested changes to this revision.Jul 23 2019, 5:44 AM
delphij added a subscriber: delphij.

What would happen for existing binaries that uses this?

ObsoleteFiles.inc
42

/lib/casper/libcap_random.so.1

This revision now requires changes to proceed.Jul 23 2019, 5:44 AM

What would happen for existing binaries that uses this?

They would fail to compile. But they are trivial to fix, since the users of the cap_random capability can be directly converted to use arc4random_buf().

Fix ObsoleteFiles.inc listing.

What would happen for existing binaries that uses this?

They would fail to compile. But they are trivial to fix, since the users of the cap_random capability can be directly converted to use arc4random_buf().

I see. I think it's fine to break API (to break at build/compile time), but my main concern was what about existing binaries that uses cap_random(3) -- will they break (I think they would because the library is now gone)?

Assuming there would be a breakage and it's serious enough that we need to take care of it (I don't have data on how many applications are using it; the previous library major version bump happened before 12-STABLE is cut, so if it breaks it would break for 12.x binary only), I think we could potentially install it through something like misc/compat12, or make this a pure shim library?

The change looks otherwise fine to me; please bump __FreeBSD_version if we go with the current approach (library gets removed) when you commit.

This revision is now accepted and ready to land.Jul 24 2019, 4:08 PM

What would happen for existing binaries that uses this?

They would fail to compile. But they are trivial to fix, since the users of the cap_random capability can be directly converted to use arc4random_buf().

I see. I think it's fine to break API (to break at build/compile time), but my main concern was what about existing binaries that uses cap_random(3) -- will they break (I think they would because the library is now gone)?

The user has to run make delete-old-libs, but yes. As far as I know, cap_random never had any users: there are none in the base system, and the number of capsicumized ports is quite low (I only know of one and it doesn't use cap_random).

Assuming there would be a breakage and it's serious enough that we need to take care of it (I don't have data on how many applications are using it; the previous library major version bump happened before 12-STABLE is cut, so if it breaks it would break for 12.x binary only), I think we could potentially install it through something like misc/compat12, or make this a pure shim library?

The change looks otherwise fine to me; please bump __FreeBSD_version if we go with the current approach (library gets removed) when you commit.

Thanks. Yes, it would be trivial to shim this library in a header file.

This revision was automatically updated to reflect the committed changes.