Re: freebsd-update: to a specific patch level - help please? [PATCH]
On 18-03-24 10:26 AM, Derek wrote: On 18-03-23 06:44 AM, Kurt Jaeger wrote: To be clear, *I've included a link to a patch to freebsd-update in my initial post, and the help I'm looking for: is to get this functionality added as a feature so others can benefit.* It works for me already, and I've already benefited. Please submit this in a PR, and post the PR number here, I'll work to get this in the tree. PR is 226893 FYI - Just awaiting any kind of feedback on the PC. Won't be starting anything until then. Derek ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-update: to a specific patch level - help please? [PATCH]
On 18-03-21 05:24 PM, Rainer Duffner wrote: Am 21.03.2018 um 22:12 schrieb Derek (freebsd lists) <48225...@razorfever.net>: Hi! I was surprised when using freebsd-update, that there was no way to specify a patch level. AFAIK, the usual answer to these kinds of requests is: „Run your own freebsd-update server“. Mirroring one of the existing ones is AFAIK neither guaranteed to work nor desired by the current „administration“. Thanks for your thoughts. To be clear, *I've included a link to a patch to freebsd-update in my initial post, and the help I'm looking for: is to get this functionality added as a feature so others can benefit.* It works for me already, and I've already benefited. (I'm happy to flesh it out, and document it properly, but I'm very hesitant to spend the time doing it in detail and submitting a PR if I'm doing this in isolation, and nobody wants it. Perhaps the silence on the thread is already a good indicator of the appetite, although I fear it's my ability to sell it or myself properly.) Structurally, "run your own freebsd-update server" is a wasteful solution for a single (or much larger set of) default install(s). It makes a lot of sense for custom installations. For what should be the default approach: repeatable - version controlled - installations with the support of the FreeBSD project, it would seem that having freebsd-update support patch levels would be a far more efficient net use of people's time than the alternatives. (I was debating both running an update server, or running "behind" a hacked up mirror as well, and in fact, I feel patching freebsd-update was a great investment, for n=1.) It’s also a somewhat transient problem now because - AFAIK - FreeBSD will see packaged base and you can probably mirror those packages and snapshot the directory at any point in time. And/Or it’s just easier to create these base-packages yourselves vs. running your own freebsd-update server. This is a good point, and perhaps why it's not worth putting more time into this. I appreciate your feedback. Thanks! Derek ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
freebsd-update: to a specific patch level - help please?
Hi! I was surprised when using freebsd-update, that there was no way to specify a patch level. In my day to day, I need to ensure security patches are applied. I also need to assess the impact of patches, and ensure consistency (ie. versions) in my environments. This can take time. Here's a story for context, please feel free to skip: We are planning to cut our 10.3-RELEASE infrastructure over to 11.1-RELEASE before the end of the month, because it's EoL in April. We updated and cut over our production load balancer March 6th (and patted ourselves on the back for being ahead of schedule), and within less than 12 hours, updated our backup load balancers. Unfortunately, we're now on ever so slightly different versions (-p6/-p7), and we're not affected by the -p7 problems. This makes my eye twitch slightly, especially when -p7 was the first patch of 2018. Now we need to upgrade our application servers, that are running our trusted code, and -p8 comes out. I'm nervous about just applying -p8, but I definitely want to upgrade to 11.1-RELEASE asap. After assessing the impact of -p8 on our infrastructure, I feel the security risk is relatively low in the short term (and we've waited this long anyway), but I feel the probability of introducing unintended side-effects is high, and want some time to test and asses. /story It would seem to me, for repeatable environments, that binary updates from FreeBSD that can be pinned to specific version are highly desireable. I've gone ahead and created a patch for my use here: https://github.com/derekmarcotte/freebsd/commit/009015a7dda5d1f1c46f4706c222614f17fb535c (there's a 10.3-specific one here: https://github.com/derekmarcotte/freebsd/commit/458879f36ae984add0ff525fb6c2765fcf1fba67 ) I'd be happy to open a PR, and to iterate and improve on this PoC, but if there's no support from the project, I'll keep it to myself. I guess what I'm asking is, for these reasons, is anyone willing to work with me (in mentorship+commit bits) to add this feature (maybe not this particular implementation) to freebsd-update? Thanks! Derek ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
Hi all, Thanks for your attention to the matter/threads. I have thought a bit about this, and I hope I can add some value to the current conversation, below: On 03/07/2014 07:36 PM, Xin Li wrote: On 03/07/14 14:50, A.J. Kehoe IV (Nanoman) wrote: Xin Li wrote: On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: [...] Honestly, my use case is just silently upgrading the strength of the hashing algorithm (when combined with my other feature request). Updating my bcrypt hashes from $2a$04$ to $2b$12$ or something. Same applies for the default sha512, maybe I want to update to rounds=15000 Like this? http://www.freebsd.org/cgi/query-pr.cgi?pr=182518 Request for comments: http://docs.freebsd.org/cgi/mid.cgi?20140106205156.GD4903 [...] Speaking for adding rounds, the only problem that needs to be fixed is that the proposed patch makes it possible to create conflicting configuration (passwd_format and passwd_modular can use different hashing algorithms) and need to be fixed and polished. I like the idea of making it possible to use more rounds though. This was deliberate for backward compatibility. passwd_format will be used by default if passwd_modular isn't defined. If passwd_modular is defined as disabled, then passwd_format will be used. Well, my point is that the two shouldn't be allowed to exist together if they can mean something conflicting. Allowing passwd_format=sha512 AND passwd_modular=$2a$08$ in the same configuration creates confusion and it's not good. Agreed. My original intention was to create a patch that didn't touch a lot of code. My reasons for this were first to see if there was any interest from a committer to take this further. Much more likely to have a 15 or so line patch looked at, than one that touches stuff all over the place - I think. We are now at least having a conversation about it. It seemed to be a lot of work to specify rounds via login_setcryptfmt, with a bunch of changes also required in libcrypt. I don't have the resources to test for regressions in libcrypt, beyond the scope of whether login.conf works as expected (specifically, the ports tree, yp, ldap, or any other areas that I don't know about). If other developers were willing to work together on the api/abi changes, I would feel a lot better about spending my time there and doing it right. Without support from other, more knowledgeable people (as far as what will break if we do XYZ), who will eventually merge productive changes, I would be wasting my time. I don't want to be the libcrypt api changing pixie, scattering patches into /dev/null. :) My suggestion is that we either have: a) passwd_format and passwd_round (so that they don't conflict), or I recommend against this. By example, based on current scrypt modular crypt RFCs, there are multiple tunable parameters. It's conceivable that other future algorithms will have different functional and named parameters. Additionally, I think having all the parsing code for this scattered about actually makes things less clear. For example, $2a$08$ means a lot more to people (across different *nix backgrounds) than blf, is concise, and is/already should be well documented in crypt(3). Likewise with sha512. Looking at login.conf, you can't tell exactly what it means. Modular crypt is something that developers are working to stay compatible with (e.g. $5$, $6$, $2y$, etc), is understood outside of the context of FreeBSD system administration, and would be understood by people who are knowledgeable enough to seek to change this aspect of their system. b) extend passwd_format in a compatible manner to allow specifying a round, or, c) make passwd_format and passwd_modular conflict so we don't silently accept it and instead bail out when doing pwd_mkdb. As jmg suggested, by supplying the modular format for passwd_format, we eliminate this conflict, and make it obvious. I definitely support this notion. That means touching login_setcryptfmt and friends, I think. What do you think of the idea of putting this into libcrypt instead of pam_unix.c, and then patching pam_unix.c and pw_user.c to reference libcrypt? Which part of the idea? I think it's a bad idea to make libcrypt to depend on libutil (for login_cap(3)) but we should probably provide new wrappers in login_cap(3) to do the common things when requested for various password manipulating tools to reduce duplicated code. Specifically: The makesalt aspect can/should be put into libcrypt, refined appropriately, and exposed publicly. It is a terrible little piece of code as it is now, twice (or more!), and it could be cleaned up considerably. This could be a nice little api. Secondly, since the digests are used externally, I think it would be good to push the custom base64 code out to a library somewhere, so there is the
