Open
Conversation
update Go version in tests update gofmt of examples fix goidentity imports in examples workaround go modules being default as of 1.16 for v7 that does not use modules
* chore: update golang.org/x/crypto (CVE-2021-43565) Whilst the particular CVE doesn't effect gokrb5 at all (it is in x/crypto/ssh) it has a high CVSS scoring and can hence cause false positives in applications making use of gokrb5 that pull in the older version unless they use `replace` directives.
all: drop use of deprecated io/ioutil package
thanks for the contribution!
Fixes jcmturner#434 As per MIT source (src/lib/krb5/krb/gen_seqnum.c) : /* * Work around implementation incompatibilities by not generating * initial sequence numbers greater than 2^30. Previous MIT * implementations use signed sequence numbers, so initial * sequence numbers 2^31 to 2^32-1 inclusive will be rejected. * Letting the maximum initial sequence number be 2^30-1 allows * for about 2^30 messages to be sent before wrapping into * "negative" numbers. */ .. and information provided on the kerberos@mit.edu mailing list : Greg Hudson <ghudson@mit.edu> Mar 26, 2021, 5:17 PM On 3/26/21 3:26 PM, Jake Scott wrote: > I took the naive approach of handling the initial sequence numbers by > simply casting the uint32 value from the authenticator and AP-REP encpart > to uint64. However that causes compatibility issues with the MIT > implementation that appears to cast first to a signed int32 and then to the > GSSAPI uint64. I think that may have been a bug introduced in 2008. In release 1.6, the GSSAPI code fetched the Kerberos sequence number into a uint32, but using a function accepting an int32 *, which caused compiler warnings. Commit abcfdaff756631d73f49103f679cafa7bc45f14e (later merged in commit 0ba5ccd7bb3ea15e44a87f84ca6feed8890f657d) the warnings were squashed by changing the variable to an int32, apparently without regard to the behavior change for Kerberos sequence numbers in the 2^31..2^32-1 range. Due to earlier history with sequence number and ASN.1 encoding bugs, MIT and Heimdal both generate Kerberos sequence numbers in the range 0..2^30-1 by masking with 0x3FFFFFFF (see krb5_generate_seq_number() in both implementations). I would speculate that Microsoft and Java do the same. That could explain why the behavior change might have gone unnoticed.
Co-authored-by: riton <remi.ferrand@cc.in2p3.fr>
…ring format Co-authored-by: bflad <bflad417@gmail.com>
Co-authored-by: jake-scott <jake@jakethesnake.dev>
Co-authored-by: jake-scott <jake@jakethesnake.dev>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.