Page MenuHomeFreeBSD

Remove cap_random(3).
ClosedPublic

Authored by markj on Jul 23 2019, 1:58 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
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

markj created this revision.Jul 23 2019, 1:58 AM
emaste accepted this revision.Jul 23 2019, 2:20 AM

LGTM

Relnotes: Yes

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
oshogbo accepted this revision.Jul 23 2019, 8:46 AM
markj added a comment.Jul 23 2019, 2:00 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().

markj updated this revision to Diff 60090.Jul 24 2019, 1:54 PM

Fix ObsoleteFiles.inc listing.

markj marked an inline comment as done.Jul 24 2019, 3:34 PM
delphij accepted this revision.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)?

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
markj added a comment.Jul 24 2019, 6:25 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.

emaste accepted this revision.Jul 24 2019, 7:11 PM
This revision was automatically updated to reflect the committed changes.