#2044 F30 Change: krb5 crypto modernization
Closed: Accepted 5 years ago by churchyard. Opened 5 years ago by bcotton.

krb5 will be removing support for DES, 3DES, crc-32, and MD4 entirely; they will not be allowed in session keys or long-term keys. Additionally, RC4 and MD5 will be marked deprecated and dangerous.


I think reverting some of the change, i.e. adding back select algorithms to allow_weak_crypto should be part of the contingency mechanism. It seems possible that once this starts being deployed we'll discover some "very important" uses in the wild and we might need a way out.

+1 nonetheless

Hmm, I now saw Jason Tibbitts' message on the mailing list. I think this needs more discussion to clarify the scope. So I'll hold my vote for now.

After 7 days the vote is (+2,0,0). Can this please be added to Monday's meeting agenda?

Yeah, I'll add this to the agenda.

Metadata Update from @sgallagh:
- Issue tagged with: meeting

5 years ago

The meeting ended with: punting to await answers to questions on the mailing list

Keeping the meeting tag for next week.

Based on the list discussion, I'm +1 - I think adding log warnings to the F28/F29 packages is sufficient.

The vote is now (+3,0,-0) after 18 days. Per the ticket policy, I am processing this Change proposal as accepted.

Metadata Update from @churchyard:
- Issue untagged with: meeting
- Issue tagged with: pending announcement

5 years ago

OT: is there a way to postpone this auto accept from happening when we decide to wait for more info? Apart from the obvious way by using the -1 vote.

OT: is there a way to postpone this auto accept from happening when we decide to wait for more info? Apart from the obvious way by using the -1 vote.

The stated purpose of the policy is to prevent tickets from languishing forever. My reading of the policy suggests that even with a -1, auto approval would trigger after an additional week. I haven't actually moved forward with this proposal yet (because I was expecting that someone might object), so I'm willing to let FESCo decide if the normal process should apply here or if it's an un-handled edge case. My main concern is that next week's FESCo meeting may lack quorum again.

Can we hold this of as if the ticket was submitted on 2019-01-17 (this is IMHO when the devel discussion got to a certain conclusion). That's not to many days extra, but it would make better sense to me.

(I'm afraid we won't reach an official FESCo conclusion about that in time for it to have an effect, but I've tried.)

Can we hold this of as if the ticket was submitted on 2019-01-17

Seems reasonable to me. I'll wait until Friday, 25 January to move forward with this.

Metadata Update from @churchyard:
- Issue untagged with: pending announcement
- Issue tagged with: meeting

5 years ago

It didn't help much due to devconf :D

Metadata Update from @churchyard:
- Issue untagged with: meeting
- Issue tagged with: pending announcement

5 years ago

Metadata Update from @churchyard:
- Issue untagged with: pending announcement
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata