On Thu, Jan 17, 2019 at 05:01:45PM -0500, Robbie Harwood wrote:
> Jason L Tibbitts III writes:
>
> >> "RH" == Robbie Harwood writes:
> >
> > RH> If I backport this to fc29, will that assuage people's concerns?
> >
> > I think it would certainly help and I wouldn't complain. In fact, I'd
> >
Jason L Tibbitts III writes:
>> "RH" == Robbie Harwood writes:
>
> RH> If I backport this to fc29, will that assuage people's concerns?
>
> I think it would certainly help and I wouldn't complain. In fact, I'd
> love to start running that as soon as I can. However, it wouldn't
> help anyon
> "RH" == Robbie Harwood writes:
RH> If I backport this to fc29, will that assuage people's concerns?
I think it would certainly help and I wouldn't complain. In fact, I'd
love to start running that as soon as I can. However, it wouldn't help
anyone who does a (supposedly supported) F28->F
Jason L Tibbitts III writes:
>> "RH" == Robbie Harwood writes:
>
> RH> Ah, I see, you're talking about the case when the enctype is already
> RH> not permitted. That all makes sense then.
>
> Right. Basically, if any one of these:
>
> * Warnings in previous versions about principals withou
> > after re-reading this thread, I'm still unclear on some issues. Please
> > correct me if I'm wrong.
> >
> > - The plan is to patch the Fedora package to remove support for some
> > algorithms above and beyond what upstream is removing right now.
>
> Upstream has never removed an algorithm. H
Zbigniew Jędrzejewski-Szmek writes:
> On Tue, Jan 08, 2019 at 04:45:53PM -0600, Jason L Tibbitts III wrote:
>> > "RH" == Robbie Harwood writes:
>>
>> RH> Ah, I see, you're talking about the case when the enctype is already
>> RH> not permitted. That all makes sense then.
>
> Hi,
>
> after
On ma, 14 tammi 2019, Robbie Harwood wrote:
Tomasz Torcz writes:
On Mon, Jan 07, 2019 at 04:12:47PM -0500, Robbie Harwood wrote:
Adam Williamson writes:
> On Thu, 2019-01-03 at 22:40 -0600, Jason L Tibbitts III wrote:
>
>> But to be fair, MIT krb5 is not known for having great error output.
Tomasz Torcz writes:
> On Mon, Jan 07, 2019 at 04:12:47PM -0500, Robbie Harwood wrote:
>> Adam Williamson writes:
>>
>> > On Thu, 2019-01-03 at 22:40 -0600, Jason L Tibbitts III wrote:
>> >
>> >> But to be fair, MIT krb5 is not known for having great error output.
>> >> Not being able to start
On Tue, Jan 08, 2019 at 04:45:53PM -0600, Jason L Tibbitts III wrote:
> > "RH" == Robbie Harwood writes:
>
> RH> Ah, I see, you're talking about the case when the enctype is already
> RH> not permitted. That all makes sense then.
Hi,
after re-reading this thread, I'm still unclear on some
On Mon, Jan 07, 2019 at 04:12:47PM -0500, Robbie Harwood wrote:
> Adam Williamson writes:
>
> > On Thu, 2019-01-03 at 22:40 -0600, Jason L Tibbitts III wrote:
> >
> >> But to be fair, MIT krb5 is not known for having great error output.
> >> Not being able to start at all because the K/M has an e
> "RH" == Robbie Harwood writes:
RH> Ah, I see, you're talking about the case when the enctype is already
RH> not permitted. That all makes sense then.
Right. Basically, if any one of these:
* Warnings in previous versions about principals without modern etypes
* Logging in the new versio
Jason L Tibbitts III writes:
>> "RH" == Robbie Harwood writes:
>>>
>>> Well certainly there isn't much you can do to fix old principals on
>>> existing systems. But the current versions should be complaining
>>> loudly when it has to issue a ticket for a principal that lacks a
>>> modern en
> "RH" == Robbie Harwood writes:
RH> I've spent a nontrivial amount of time working on improving that,
RH> but am always willing to process more bugs in the
RH> documentation/errors area.
I know, and I don't mean to denigrate any work that's been done in
making the MIT KRB stack better. It'
Jason L Tibbitts III writes:
>> "RH" == Robbie Harwood writes:
>
> RH> I really don't think that "it won't work and there'll be error
> RH> messages" is an "extremely optimistic description".
>
> But to be fair, MIT krb5 is not known for having great error output.
I've spent a nontrivial am
Adam Williamson writes:
> On Thu, 2019-01-03 at 22:40 -0600, Jason L Tibbitts III wrote:
>
>> But to be fair, MIT krb5 is not known for having great error output.
>> Not being able to start at all because the K/M has an enctype which is
>> acceptable and not at all deprecated according to the doc
On Thu, 2019-01-03 at 22:40 -0600, Jason L Tibbitts III wrote:
> > > > > >
> But to be fair, MIT krb5 is not known for having great error output.
> Not being able to start at all because the K/M has an enctype which is
> acceptable and not at all deprecated according to the documentation that
> ex
> "RH" == Robbie Harwood writes:
RH> Per your follow-up email, I'm not clear on whether you want changes
RH> here. If you do, speak up, especially if you have suggestions.
Well, it was just odd that the summary had information not contained at
all within the detailed description. Since thi
On Thu, 2019-01-03 at 23:07 +, Robbie Harwood wrote:
> > BC> == Detailed Description ==
> >
> >
> > Is it just me or does this not actually say clearly what is changing?
> > The first paragraph talks about two RFCs. The second paragraph talks
> > about how easy it is to break single DES. Th
> BC> == Detailed Description ==
>
>
> Is it just me or does this not actually say clearly what is changing?
> The first paragraph talks about two RFCs. The second paragraph talks
> about how easy it is to break single DES. The third paragraph talks
> about how disabled by default is undesirabl
Raphael, I'm confused how this doesn't comply. Their source code lives here:
https://github.com/h1kari/des_kpt
Also, let's keep comments on this thread *and CC me* - then there's only one
place to look for replies (and I'm not subscribed to this list). In any case,
as I stated there, if you h
Nikos Mavrogiannopoulos writes:
> How does this ties with crypto policies? libkrb5 is already under
> crypto policies and has these ciphers disabled by default. Is this
> change about removing them from the code or removing them from the
> capabilities of the KDC which is not covered by crypto po
> "JLT" == Jason L Tibbitts writes:
JLT> Is it just me or does this not actually say clearly what is
JLT> changing?
Seems it's just me; somehow that's in the summary but not in the
detailed description. Seems odd for the details to have less
information than the short version, but I guess t
> "BC" == Ben Cotton writes:
BC> == Detailed Description ==
[elided]
Is it just me or does this not actually say clearly what is changing?
The first paragraph talks about two RFCs. The second paragraph talks
about how easy it is to break single DES. The third paragraph talks
about how dis
On Fri, 2018-12-21 at 15:35 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/krb5_crypto_modernization
>
> 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 mar
Hi,
personally, I don't like the advertisment for that commercial service, see the
given price and link. It does not comply with FLOSS policies, therefore I
commented in the releng ticket.
Just my 5ct, Raphael
___
devel mailing list -- devel@lists.fed
https://fedoraproject.org/wiki/Changes/krb5_crypto_modernization
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.
== Owner ==
* Name: [[User:rharwoo
26 matches
Mail list logo
