On 05/29/2012 02:16 PM, Devan Goodwin wrote:
> On 05/29/2012 02:53 PM, James Bowes wrote:
>> 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
>
Why get consumers/{uid}? That seems like an odd side effect?
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
My mistake, I thought entitlement certificates were in that JSON but
they are not. I will update design and remove it.