On Sat, Jun 01, 2013 at 02:37:19PM -0300, Devan Goodwin wrote:
> On 05/25/2012 04:38 PM, Devan Goodwin wrote:
>> On Fri 25 May 2012 04:18:02 PM ADT, Devan Goodwin wrote:
>>> On 05/25/2012 04:02 PM, James Bowes wrote:
>>>> I mean the quantity in the entitlement decreases, rather than the
>>>> quantity in the pool.
>>>
>>> Ah yes, that might need more fleshing out, I think I missed that there
>>> is a path to regenerate, not just revoke in there. I will revisit that.
>>
>> Ok as per IRC discussion, if a cert needs to regen because it's quantity
>> changed (due to a decrease in the subscription), we will immediately
>> revoke and regen.
>>
>>>
>>>>
>>>>> Content set changes are indeed not detectable, but possibly being
>>>>> triggered by IT to mass regenerate via that product specific API
>>>>> call. We will not know why we're being triggered though so as it
is
>>>>> today, we cannot decide if we're going to CRL now or later when
we
>>>>> regenerate. However as per next point I am hoping we can keep it
>>>>> simple and have only two situations.
>>>>>
>>>>> For products being removed I will wager we still do not want to add
>>>>> to the CRL immediately, driver here was to not invalidate
>>>>> distributor certificates and my guess is we should not be doing that
>>>>> even if we're removing access to a particular repo from their
>>>>> subscription. Can we get clarification on this? (should we
>>>>> immediately invalidate certificates if a product is removed from a
>>>>> subscription)
>>>>>
>>>>
>>>> I'm pretty sure this is the exact situation where we do want to add
to
>>>> the CRL. removing a product or a content set means you should no longer
>>>> have access to that content. If all a nefarious consumer has to do to
>>>> keep accessing content they're not rightly entitled to is to not ask
for
>>>> a new cert, candlepin isn't doing its job.
>>>
>>> It's possible but I think we need to check, if I am reading the user
>>> story notes correctly, removal of content sets is listed explicitly as
>>> one of the scenarios where we want lazy revocation. i.e. we removed
>>> some content from your entitlement (in this case a provided product
>>> and it's content), but we do not want to immediately break all those
>>> downstream consumers.
>>>
>>> Candlepin could still be doing it's job if we reject immediately on
>>> loss of entitlement, but take a tolerant approach to rejecting
>>> certificates because we changed something on our end. Highly unlikely
>>> a nefarious consumer is going to anticipate a change to our product
>>> data, and shut off all consumer check-ins as far as I can forsee. It
>>> all depends on why this is being requested though.
>>>
>>
>> And for this we're going to assume content / product removal is still a
>> lazy operation by default, but both refresh pools for owner, and
>> regenerate all certs for a given product ID API calls will take an
>> option to force immediate certificate revocation. This is a safety net
>> in case something was granted that really should not have been.
>>
>>
>> I will write this all up on wiki and break down into tasks next week.
>>
>> Cheers,
>>
>> Devan
>> _______________________________________________
>> candlepin mailing list
>> candlepin(a)lists.fedorahosted.org
>>
https://fedorahosted.org/mailman/listinfo/candlepin
>
> Design is up at
https://fedorahosted.org/candlepin/wiki/LazyCertRegen
>
> Please have a look at let me know if anything needs to be clarified.
>
> Thanks,
under task 2 you have "Be sure". Sentance fragment or way of life?
Maybe add a note that the regeneration that goes with an immediate CRL
can be either lazy or immediate, depending on which is cleaner in the
code.
-James
Thanks, added.
Sorry about the previous future email as well all, date testing cert
expiration again. :)
Devan