Page MenuHomeFreeBSD

david_crossfamilyweb.com (David Cross)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 8 2018, 10:05 PM (370 w, 4 d)

Recent Activity

Oct 23 2024

david_crossfamilyweb.com requested review of D47261: NS_RETURN incorrectly excluded from terminal states with custom status return rules.
Oct 23 2024, 3:22 AM

Oct 18 2024

david_crossfamilyweb.com updated the summary of D47189: nscd corretly handle end of stream for getent.
Oct 18 2024, 10:30 PM
david_crossfamilyweb.com updated the diff for D47189: nscd corretly handle end of stream for getent.

Update diff with -U99999

Oct 18 2024, 10:28 PM
david_crossfamilyweb.com requested review of D47189: nscd corretly handle end of stream for getent.
Oct 18 2024, 10:28 PM
david_crossfamilyweb.com updated the diff for D47148: nscd step6.

Implemented all PR changes

Oct 18 2024, 5:44 AM
david_crossfamilyweb.com updated the diff for D47147: nscd step5.

Implemented all changes save for pulling thread safety into step4

Oct 18 2024, 5:09 AM
david_crossfamilyweb.com updated the summary of D47147: nscd step5.
Oct 18 2024, 5:06 AM
david_crossfamilyweb.com updated the diff for D47146: nscd step4.

implemented all PR changes

Oct 18 2024, 4:47 AM
david_crossfamilyweb.com updated the diff for D47143: nscd -- step1.

All changes minus L771 one

Oct 18 2024, 4:23 AM

Oct 17 2024

david_crossfamilyweb.com added a comment to D47144: nscd step2.

We shouldn't need it. The only consumer of this function is __ns_mp_cache_read in nscache.clli.
Line 296 we loop until res != -2 (which is an internal state). so when we leave that loop we know we're in some kind of terminal protocol state.

Oct 17 2024, 6:53 PM
david_crossfamilyweb.com added a comment to D47143: nscd -- step1.

change the cycle breakout flow a bit, previous flow would just bypass the cache lookup and call "method()" which was coded in the cache provider to return NS_UNAVAIL. this just calls continue() to bypass this call entirely. (note this will have the advantage in the future where we can move that cache call INTO "method" for the caching module making the code more similar between methods.

I see that you broke out your nss diffs into quite a few different pieces - thank you.

The change referenced above is something I would move into a separate patch. It has no functional effect on its own and it makes control flow more indirect - when looking at the cache lookup call, I have to remember that an earlier check ensures that that code will be skipped if nsdispatch is running within nscd.

I don't insist on moving it to a separate diff this time, but in the future please try to avoid mixing different types of changes in a single patch. If the patch aims to fix a bug, don't also make control flow changes that ease future refactoring. If the patch makes cosmetic improvements and style fixes, please don't also include bug fixes, etc. etc..

Oct 17 2024, 6:00 PM
david_crossfamilyweb.com added inline comments to D47144: nscd step2.
Oct 17 2024, 5:48 PM

Oct 16 2024

david_crossfamilyweb.com requested review of D47149: nscd step7.
Oct 16 2024, 3:13 AM
david_crossfamilyweb.com requested review of D47148: nscd step6.
Oct 16 2024, 3:10 AM
david_crossfamilyweb.com requested review of D47147: nscd step5.
Oct 16 2024, 2:51 AM
david_crossfamilyweb.com requested review of D47146: nscd step4.
Oct 16 2024, 2:26 AM
david_crossfamilyweb.com requested review of D47145: nscd step3.
Oct 16 2024, 2:14 AM
david_crossfamilyweb.com requested review of D47144: nscd step2.
Oct 16 2024, 2:06 AM
david_crossfamilyweb.com requested review of D47143: nscd -- step1.
Oct 16 2024, 1:48 AM
david_crossfamilyweb.com updated the diff for D38047: Multiple fixes to the NSS caching system.

rebasing with minor additional changes before I begin the work to split this up

Oct 16 2024, 1:13 AM · Src Committers

Oct 13 2024

david_crossfamilyweb.com added inline comments to D38047: Multiple fixes to the NSS caching system.
Oct 13 2024, 6:45 PM · Src Committers
david_crossfamilyweb.com updated the diff for D38047: Multiple fixes to the NSS caching system.

Interim PR changes while I work on splitting this up to different sub PRs. Don't want my work lost

Oct 13 2024, 1:01 AM · Src Committers
david_crossfamilyweb.com added inline comments to D38047: Multiple fixes to the NSS caching system.
Oct 13 2024, 12:56 AM · Src Committers

Sep 21 2024

david_crossfamilyweb.com added a comment to D38047: Multiple fixes to the NSS caching system.

Possible to get some eyes on this and see if we can get this across?

Sep 21 2024, 7:48 PM · Src Committers
david_crossfamilyweb.com added a comment to D45056: support for DIRECT access via ggated and ggatec.

With many apologies for the delay, this is now sent.

Sep 21 2024, 7:37 AM · Src Committers

Sep 8 2024

david_crossfamilyweb.com added a comment to D45056: support for DIRECT access via ggated and ggatec.

How should I submit this to you for the path; I have never used git format-patch before; I tried doing git format-patch main and it generated 21 files (since I have 21 commits). Manpage suggests I email this to you? But it seems rude to just blast you with 21 patches; and I don't know your email.

David, did you still need more help here?

Sep 8 2024, 1:41 AM · Src Committers

Aug 24 2024

david_crossfamilyweb.com added a comment to D45056: support for DIRECT access via ggated and ggatec.

How should I submit this to you for the path; I have never used git format-patch before; I tried doing git format-patch main and it generated 21 files (since I have 21 commits). Manpage suggests I email this to you? But it seems rude to just blast you with 21 patches; and I don't know your email.

Aug 24 2024, 7:27 AM · Src Committers
david_crossfamilyweb.com updated the diff for D45056: support for DIRECT access via ggated and ggatec.

Updated with last PR fixes

Aug 24 2024, 7:15 AM · Src Committers

Aug 16 2024

david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.

Is there anything I can do here?

Aug 16 2024, 4:55 PM · Loader

Aug 15 2024

david_crossfamilyweb.com updated the diff for D38047: Multiple fixes to the NSS caching system.

Rebase and remove unnecessary () in an if check (per review comment)

Aug 15 2024, 3:30 AM · Src Committers

Aug 14 2024

david_crossfamilyweb.com updated the diff for D41509: crypt(3) style password support for lua loader.

Updated to remove the extra newline

Aug 14 2024, 8:26 PM · Loader

Aug 13 2024

david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.

Should note I just got done testing this with a clean 14.1 src tree that I applied the git diff to with no other changes; tested sha256 password and sha512 password, additionally un-commented both test vector suites and all passed.

Aug 13 2024, 2:00 AM · Loader
david_crossfamilyweb.com updated the diff for D41509: crypt(3) style password support for lua loader.

Updated the diff per requested copyright changes.

Aug 13 2024, 1:52 AM · Loader

Aug 12 2024

david_crossfamilyweb.com updated the diff for D41509: crypt(3) style password support for lua loader.

Synced with latest freebsd/main for diff generation, no other changes

Aug 12 2024, 6:52 PM · Loader
david_crossfamilyweb.com updated the diff for D41509: crypt(3) style password support for lua loader.

As promised, updated, including modifications to export sha512 from C, updated lua crypt implementation to use exported C routines, removed the now unneeded pure lua implementation, I ran all validation suites on my computer and this is passing.

Aug 12 2024, 6:49 PM · Loader

Aug 11 2024

david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.
In D41509#1055136, @imp wrote:

Great! I'd forgotten I'd only included it in kboot since that's the only place I'd tested it.
I'll include it elsewhere by default. IIRC, the lua glue code is only about 200 extra bytes of code, so we can have it in the BIOS loader. We're not that close to the edge on it. Normally, I'd say no new features there, but this is a reasonable exception. The big ones that will be hard in the future is there will be no new ZFS compression or crypto supported there.

Aug 11 2024, 8:23 PM · Loader
david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.
In D41509#1054254, @imp wrote:

I can work on that and validate it; checking quickly it looks like the version exported is compatible (the big issue with other implementations was being given the binary form of the hash to work with, your export seems to do that).

However only sha256 seems to be available there; sha512 is the default for password hashing. I only had done the sha256 since the structure was so similar to sha512 in both the hash mechanism and crypt(3) mechanism that it was easy, but SHA512 was the primary target.

I can add it easily enough. I just didn't need it for the thing I was working on.

Could I get a quick pointer as to accessing these in the code?

I've tried 'require("hash")' and 'loader.sha256' and even 'loader.hash.sha256') (tried modeling these after the gfx module which seems at a high level to be implemented the same way: LUA_COMPILE_SET() to an _init function that luaL_require the module,and then accessing it via the loader hash, but no matter what I try I get a nil dereferene

Aug 11 2024, 2:15 AM · Loader

Aug 9 2024

david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.
In D41509#1054254, @imp wrote:

I can work on that and validate it; checking quickly it looks like the version exported is compatible (the big issue with other implementations was being given the binary form of the hash to work with, your export seems to do that).

However only sha256 seems to be available there; sha512 is the default for password hashing. I only had done the sha256 since the structure was so similar to sha512 in both the hash mechanism and crypt(3) mechanism that it was easy, but SHA512 was the primary target.

I can add it easily enough. I just didn't need it for the thing I was working on.

Aug 9 2024, 9:30 PM · Loader

Aug 6 2024

david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.
In D41509#1054254, @imp wrote:

I can work on that and validate it; checking quickly it looks like the version exported is compatible (the big issue with other implementations was being given the binary form of the hash to work with, your export seems to do that).

However only sha256 seems to be available there; sha512 is the default for password hashing. I only had done the sha256 since the structure was so similar to sha512 in both the hash mechanism and crypt(3) mechanism that it was easy, but SHA512 was the primary target.

I can add it easily enough. I just didn't need it for the thing I was working on.

Aug 6 2024, 4:27 PM · Loader
david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.

I can work on that and validate it; checking quickly it looks like the version exported is compatible (the big issue with other implementations was being given the binary form of the hash to work with, your export seems to do that).

Aug 6 2024, 3:56 PM · Loader

Jul 13 2024

david_crossfamilyweb.com updated the diff for D45056: support for DIRECT access via ggated and ggatec.

Previous version did have one compile error (missing ;) in the file I warned I had not tested; also updated usage to match man pages

Jul 13 2024, 5:04 AM · Src Committers

May 10 2024

david_crossfamilyweb.com updated the diff for D41509: crypt(3) style password support for lua loader.

updated diff -U 99999

May 10 2024, 5:19 PM · Loader
david_crossfamilyweb.com updated the diff for D38047: Multiple fixes to the NSS caching system.

Updated diff -U99999

May 10 2024, 5:18 PM · Src Committers

May 9 2024

david_crossfamilyweb.com updated the diff for D45056: support for DIRECT access via ggated and ggatec.

Updated with PR comments

May 9 2024, 6:18 PM · Src Committers
david_crossfamilyweb.com added inline comments to D45056: support for DIRECT access via ggated and ggatec.
May 9 2024, 6:18 PM · Src Committers

May 2 2024

david_crossfamilyweb.com updated the diff for D45056: support for DIRECT access via ggated and ggatec.

Updated for -U99999 as requested.

May 2 2024, 5:16 PM · Src Committers
david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.

Could this be imported as is, and then when the hash modules are in and exported it could be switched over?

May 2 2024, 6:06 AM · Loader
david_crossfamilyweb.com added a comment to D38047: Multiple fixes to the NSS caching system.

I believe I have addressed all of reviews; it would be great to get this in for 14.1 so I don't keep having to patch my local copies

May 2 2024, 6:04 AM · Src Committers
david_crossfamilyweb.com requested review of D45056: support for DIRECT access via ggated and ggatec.
May 2 2024, 6:00 AM · Src Committers

Apr 18 2024

david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.
In D41509#1022312, @imp wrote:

I've created a hash module that has some of the sha routines. I don't have big issues connecting those.

Apr 18 2024, 3:54 PM · Loader
david_crossfamilyweb.com updated the diff for D41509: crypt(3) style password support for lua loader.

Updated with all PR comments, save 1.

Apr 18 2024, 3:21 PM · Loader

Aug 26 2023

david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.
  1. Updated documentation
Aug 26 2023, 4:47 AM · Loader
david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.
  1. refactored tests to make them easier to add to.
Aug 26 2023, 4:46 AM · Loader
david_crossfamilyweb.com updated the diff for D41509: crypt(3) style password support for lua loader.

Updated diff with all comments addressed, specifically:

  1. hashes.lua removed and moved into crypt.lua with no reexport
  2. tests refactored
  3. tests for NIST vectors for SHA256/512 added (and verified)
  4. added "crypt:" prefix on password
Aug 26 2023, 4:45 AM · Loader

Aug 23 2023

david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.

Thinking about this, I can make a couple of changes that could make this more palatable:

Aug 23 2023, 10:02 PM · Loader
david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.
In D41509#947260, @jhb wrote:

Ok, this is fine, but if we're going to go through the effort of exporting C routines to the lua environment I'd STRONGLY advocate just exposing crypt(3). For numerous reasons:

Unfortunately I don't think that's really feasible, particularly not without a build knob to turn it off. Keep in mind that biosloader is heavily constrained (under 512k-ish total) and we're already pushing the envelope on that, enough so that various downstreams do actually have to turn various things off to fit everything they need in loader (this is why I was wondering about the size requirements of moving sha256/512 of the GELI knob).

But that just means we don't support non-plaintext passwords for the BIOS loader, right? It would basically mean that we would not be adding this new feature for that case (which is becoming more and more obsolete) but would be adding the new feature everywhere else. That tradeoff is probably fine. Exporting just crypt(3) also I think narrows your concerns about other people deciding to use SHA hashes in other places.

Aug 23 2023, 9:55 PM · Loader
david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.
In D41509#947261, @imp wrote:

btw, lua's math.* aren't included because float/double math isn't included and I thought there's very little there that doesn't use it. If my thoughts are wrong, of course we can reconder.

Aug 23 2023, 9:52 PM · Loader

Aug 20 2023

david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.

Uncomfortable how? This is a very straightforward implementation of SHA256/SHA512 modeled after existing LUA SHA2 libraries. I only reimplemented because:

The problem is that now the implementation will exist, and thus it will get used for uses that we aren't anticipating and it becomes crypto code that actually should be audited.

  1. existing ones were based on lua <5.4 and relied on the bit32 library which is not in LUA54
  2. were vastly overcomplicated and not BSD licensed (ones that worked on every version of LUA and included multiple different sub-implementations optimized for a vast number of possible LUA configurations.)
  3. were incapable of being used in this context (they would return hex encoded values, where the crypt(3) algorithms require the raw binary to feed into subsequent stages

Exposing SHA2 from to loader in this way would be complicated that would require either:

  1. exposing complex 'context' objects to the underlying scripting language, since crypt(3) builds up the hashes with multiple updates, with those needing to be constructed/initialized, returned, and passed to subsequent calls for update and finalization
    • or -
  2. rewriting the crypt(3) routines to concatenate their entire requests together into a single call such that it could be wrapped into a single shaX() that would return the binary result. I guess technically the crypt(3) implementation could unenode the hex to get back the binary.. gross. Regardless this would mean fairly substantial rewrite of the crypt implementation, and constructing kilobyte strings to sling the data around in the interpreter.

Honestly the crypt(3) implementation frightens me much worse, that is a grotesquely overly complicated algorithm.

If we were to export anything to the loader(8) level the right choice would be libcrypt; I looked at doing that originally but figured this would much less invasive to loader and easier to get in since it was entirely in the interpreter level.

I don't know where you get the idea that you'd need crypt(3), to be honest. In my first comment, I noted that we already have sha256/sha512 available in libsa that could be broken out relatively easily (same API that's seen in libmd). You don't even need the complex context you suggested, you can still do closures just fine in C and keep your consumers as-is. I'd even be willing to write said replacement if you'd use it, but I need to check how much size we gain in non-default loader configurations if we move sha256/sha512 out from behind the GELI knob.

But, what exactly is uncomfortable? This is used ONLY for doing the password hash, nothing is being validated/signed against this, there's no network access, it only even comes into play to match a provided password that someone who already had root access had to set.
It is *explicitly* extensively tested (I tested every sequence of 0s from none to 65536 and compared to sha256/sha512) offline (I didn't include those)
It is *implicitly* extensively tested (I included all provided test vectors of crypt for $5$ and $6$), (these are included in the source) and they all passed, which puts the sha libraries through a rather thorough torture test themselves.

Already generally answered above, but to re-iterate: for your current use it's perfectly fine, but as soon as it's made available it becomes a public API that could actually get used for more sensitive applications that we didn't anticipate or want.

Aug 20 2023, 5:19 PM · Loader
david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.

Why do we even have support of loader password other than unlocking the GELI provider in the first place? Or in other words, what was the threat model it's trying to protect the user from?

No idea where it originated, I just ported it from 4th.

I think password.lua should only support entering passphrases for unlocking encrypted providers, and absolutely nothing beyond that. Storing passphrase material in the unencrypted boot storage is calling all kinds of problems and I can't see real security benefits of doing over using e.g. GELI.

IMO we can't easily get rid of these; one is to prevent boot entirely if you don't have the password, the other is to just prevent user from getting to the loader menu. At least for bootlock_password, the most obvious application I think is to prevent a local user from pushing the system into single-user mode assuming they don't have any other access to the box.

Aug 20 2023, 5:09 PM · Loader
david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.

Why do we even have support of loader password other than unlocking the GELI provider in the first place? Or in other words, what was the threat model it's trying to protect the user from?

I think password.lua should only support entering passphrases for unlocking encrypted providers, and absolutely nothing beyond that. Storing passphrase material in the unencrypted boot storage is calling all kinds of problems and I can't see real security benefits of doing over using e.g. GELI.

These have existed for decades and pretty much every boot loader and every link in the booting process has optional passwords in place as a check against random people interfering with the boot process. BIOS has it, openboot has it, grub has it.

Aug 20 2023, 5:07 PM · Loader
david_crossfamilyweb.com added a comment to D41509: crypt(3) style password support for lua loader.

Uncomfortable how? This is a very straightforward implementation of SHA256/SHA512 modeled after existing LUA SHA2 libraries. I only reimplemented because:

  1. existing ones were based on lua <5.4 and relied on the bit32 library which is not in LUA54
  2. were vastly overcomplicated and not BSD licensed (ones that worked on every version of LUA and included multiple different sub-implementations optimized for a vast number of possible LUA configurations.)
  3. were incapable of being used in this context (they would return hex encoded values, where the crypt(3) algorithms require the raw binary to feed into subsequent stages
Aug 20 2023, 3:45 AM · Loader

Aug 19 2023

david_crossfamilyweb.com requested review of D41509: crypt(3) style password support for lua loader.
Aug 19 2023, 10:00 PM · Loader

Aug 4 2023

david_crossfamilyweb.com updated the diff for D38047: Multiple fixes to the NSS caching system.

Cleaned up erroneous patches due to my tree being out of date with target.

Aug 4 2023, 5:50 AM · Src Committers
david_crossfamilyweb.com added a comment to D38047: Multiple fixes to the NSS caching system.

Ran entire kyua test suite as follows:

Aug 4 2023, 5:34 AM · Src Committers
david_crossfamilyweb.com updated the diff for D38047: Multiple fixes to the NSS caching system.

Updates from code review

Aug 4 2023, 5:32 AM · Src Committers
david_crossfamilyweb.com added inline comments to D38047: Multiple fixes to the NSS caching system.
Aug 4 2023, 5:30 AM · Src Committers

Jan 19 2023

david_crossfamilyweb.com added a comment to D38047: Multiple fixes to the NSS caching system.
In D38047#865895, @pauamma wrote:

Does this need any corresponding updates to manual pages, eg getpwent(3), getgrent(3), nsswitch.conf(5), or nscd(8)? My C reading skills aren't up to telling conclusively.

Jan 19 2023, 10:43 PM · Src Committers

Jan 13 2023

david_crossfamilyweb.com requested review of D38047: Multiple fixes to the NSS caching system.
Jan 13 2023, 11:21 PM · Src Committers