In D15801#336741, @eadler wrote:

Steal space from RES and SIZE; incrase username

In D16072#340510, @ygy wrote:

@loader @delphij What I am unsure is zh_CN.UTF-8/htdocs/developers.xml. Is it used anywhere, and should we keep maintaining it?

Looks reasonable.

Adding kib@ and emaste@. (I think secteam@ do want to pay attention on this one but is probably more of a "FYI" or "Cc" role rather than a reviewer but thanks for the heads up).

In D15886#336083, @sef wrote:

In D15886#336082, @delphij wrote:

In D15886#336048, @sef wrote:

Is it possible to provide a switch to disable the SETQUOTA RPC?

Sorry, I meant a command line option to rpc.rquotad if it's not clear.

I don't have any code in there right now that handles the SETQUOTA RPC, so I'm still confused. Want to discuss it in email?

In D15886#336048, @sef wrote:

Is it possible to provide a switch to disable the SETQUOTA RPC?

I'm not sure what you mean by a switch there?

Is it possible to provide a switch to disable the SETQUOTA RPC? (Assuming I'm understanding correctly that no additional authentication is done before it's permitted; rpc.rquotad runs at root privilege so when it issues vfs_quotactl it would not fail because insufficient privilege).

LGTM in principal.

Address reviewer comments.

Accept as secteam@ -- talked with so@ and we have no objection to the change in principal.

The change LGTM in principal but I'd like to request a few minor (cosmetic) change.

Mostly LGTM. Is there a reason to keep these #if 0's in tools/tools/crypto/cryptocheck.c?

I think you should exit(EX_OK) or return 0 in main(); without it the compiler would give a warning and caller may or may not get wrong exit status (of whatever was left in %rax) at the point. The change otherwise looks good to me.

LGTM.

Looks good to me in principal.

LGTM, thanks!

Just in case an explicit blessing from secteam is needed.

LGTM, thanks!

Oops, I thought I have send out the comment but turns out I didn't.

Could you please create a review of just the sys/dev/random/randomdev.c portion of change (see my comments inline) as this is a self-contained bugfix and is orthogonal to the rest part of this review? It's easier to understand smaller changesets and future readers of code history would have an easier time to see the reasoning when they are done in smaller and self-contained units.

You have not updated manual page, but the change looks otherwise fine to me.

Please take a look at comments inline.

Please do not remove O3: Kernel Random Numbers Generator from reviewers, the proposed change have material impact to the kernel random number generator's behavior and I don't think it's Okay to bypass it.

In D14500#304788, @cem wrote:

In D14500#304661, @delphij wrote:

In D14500#304139, @cem wrote:

In D14500#304100, @delphij wrote:

The same criticism can be leveled at /dev/urandom. This uses the exact same kernel interface (READ_RANDOM_UIO).

Yes, but my understanding is this new API is intended for all applications (while /dev/urandom access may be blocked with permission), e.g. an application in capability mode should have access to it.

I guess so, but the concern is still a completely hypothetical attack against SHA256 and Fortuna. And maybe a local DoS — I'm still unclear on that.

I don't see any problem in principle, the restriction was introduced in r21052 but it didn't explained why it was introduced, and looks like other operating systems, nor LDAP's posixAccount schema seem to enforce similar restrictions.

In D14500#304139, @cem wrote:

What specific changes do you want made?