On 06/16/2017 05:11 PM, Richard Purdie wrote:
> On Fri, 2017-06-16 at 13:43 -0500, Alejandro del Castillo wrote:
>>
>> On 06/16/2017 03:46 AM, Richard Purdie wrote:
>>>
>>> There is the potential for sensitive information to leak through
>>> the urls
>>> there and removing it brings this into the
On Fri, 2017-06-16 at 13:43 -0500, Alejandro del Castillo wrote:
>
> On 06/16/2017 03:46 AM, Richard Purdie wrote:
> >
> > There is the potential for sensitive information to leak through
> > the urls
> > there and removing it brings this into the behavior of the other
> > package
> > backends si
On 06/16/2017 03:46 AM, Richard Purdie wrote:
> There is the potential for sensitive information to leak through the urls
> there and removing it brings this into the behavior of the other package
> backends since filtering it is likely error prone.
>
> Since ipks don't appear to be generated at
On Fri, Jun 16, 2017 at 10:22:35AM +0100, Richard Purdie wrote:
> On Fri, 2017-06-16 at 09:46 +0100, Richard Purdie wrote:
> > There is the potential for sensitive information to leak through the
> > urls
> > there and removing it brings this into the behavior of the other
> > package
> > backends
On Fri, 2017-06-16 at 09:46 +0100, Richard Purdie wrote:
> There is the potential for sensitive information to leak through the
> urls
> there and removing it brings this into the behavior of the other
> package
> backends since filtering it is likely error prone.
>
> Since ipks don't appear to be
There is the potential for sensitive information to leak through the urls
there and removing it brings this into the behavior of the other package
backends since filtering it is likely error prone.
Since ipks don't appear to be generated at all if we don't set this, set
the field to the recipe nam
