Page MenuHomeFreeBSD

Remove cap_random(3).
ClosedPublic

Authored by markj on Jul 23 2019, 1:58 AM.
Tags
None
Referenced Files
Unknown Object (File)
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

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

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 ↗(On Diff #60037)

/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.