Re: plasma 5.24 tars ready for packaging

2022-02-10 Thread Nate Graham

On 2/10/22 11:07, Ben Cooksley wrote:
Hence the feeling of impending doom (imagine if you were getting a flood 
of bug reports about a single issue and knew that it was only going to 
get bigger before it got smaller)


JFYI there is no need to imagine; that's literally the everyday reality 
for people doing bug triage. You get a flood of bug reports, you triage 
them and alert the developers, the developers try their best to fix the 
issue and eventually do so, you alert packagers to backport the fix as 
needed; this is how it works.



Nate


Re: plasma 5.24 tars ready for packaging

2022-02-10 Thread Ben Cooksley
On Fri, Feb 11, 2022 at 1:23 AM Aleix Pol  wrote:

> On Wed, Feb 9, 2022 at 11:05 AM Ben Cooksley  wrote:
> >
> > On Wed, Feb 9, 2022 at 4:30 AM Nate Graham  wrote:
> >>
> >> Much work is currently in progress to actually fix these issues. I see
> >> multiple merge requests across multiple repos being reviewed and merged.
> >> I think it makes sense to let that process happen. I see no indication
> >> of the issue not being taken seriously, even considering the hyperbolic
> >> and threatening way in which it was communicated mere days before a
> >> major software release that is already occupying everyone's time. Let's
> >> tone down the rhetoric and let developers do their jobs, now that
> >> they've been made aware of this critical issue.
> >
> >
> > Please note that it is extremely important that backports and the making
> of releases containing those backports is a critical part of the process of
> rectifying this issue.
> > It cannot be left to just resolve itself via the organic process of
> users updating their systems to major versions - because that won't happen
> for months or longer and it is likely that the issue will continue to
> intensify before it gets any better.
> >
> > Based on data we have we know that a big proportion of the traffic is
> coming from KF 5.86 based systems so these patches need backporting as
> distributions will not ship major version updates to these users.
> > Patch releases however have a chance (especially if we prod packagers)
> of making their way to those users within a matter of days.
> >
> > To date all mentions I have made of backports being essential have been
> ignored.
>
> I don't know why you are saying you have been ignored. Distributions
> were notified yesterday and I know at least a portion of them are
> working on it.
>

Please note the timing of the email - it predates the backport request
emails being sent.
Now that the backports process is underway things are looking much better.


>
> This problem has been ongoing for several weeks now. Mitigations are
> in place, let's give ourselves the time to react.
>
> I don't think that this general feeling of impending doom is making it
> easier for anyone to address the problem.
>

Prior to the backport process getting underway we were facing the
possibility of the issue dragging on for many months, with the issue
potentially intensifying during that period.
Hence the feeling of impending doom (imagine if you were getting a flood of
bug reports about a single issue and knew that it was only going to get
bigger before it got smaller)



>
> Thank you for caring.
> Aleix
>

Thanks,
Ben


Re: plasma 5.24 tars ready for packaging

2022-02-10 Thread Aleix Pol
On Wed, Feb 9, 2022 at 11:05 AM Ben Cooksley  wrote:
>
> On Wed, Feb 9, 2022 at 4:30 AM Nate Graham  wrote:
>>
>> Much work is currently in progress to actually fix these issues. I see
>> multiple merge requests across multiple repos being reviewed and merged.
>> I think it makes sense to let that process happen. I see no indication
>> of the issue not being taken seriously, even considering the hyperbolic
>> and threatening way in which it was communicated mere days before a
>> major software release that is already occupying everyone's time. Let's
>> tone down the rhetoric and let developers do their jobs, now that
>> they've been made aware of this critical issue.
>
>
> Please note that it is extremely important that backports and the making of 
> releases containing those backports is a critical part of the process of 
> rectifying this issue.
> It cannot be left to just resolve itself via the organic process of users 
> updating their systems to major versions - because that won't happen for 
> months or longer and it is likely that the issue will continue to intensify 
> before it gets any better.
>
> Based on data we have we know that a big proportion of the traffic is coming 
> from KF 5.86 based systems so these patches need backporting as distributions 
> will not ship major version updates to these users.
> Patch releases however have a chance (especially if we prod packagers) of 
> making their way to those users within a matter of days.
>
> To date all mentions I have made of backports being essential have been 
> ignored.

I don't know why you are saying you have been ignored. Distributions
were notified yesterday and I know at least a portion of them are
working on it.

This problem has been ongoing for several weeks now. Mitigations are
in place, let's give ourselves the time to react.

I don't think that this general feeling of impending doom is making it
easier for anyone to address the problem.

Thank you for caring.
Aleix


Re: plasma 5.24 tars ready for packaging

2022-02-09 Thread Ben Cooksley
On Wed, Feb 9, 2022 at 4:30 AM Nate Graham  wrote:

> Much work is currently in progress to actually fix these issues. I see
> multiple merge requests across multiple repos being reviewed and merged.
> I think it makes sense to let that process happen. I see no indication
> of the issue not being taken seriously, even considering the hyperbolic
> and threatening way in which it was communicated mere days before a
> major software release that is already occupying everyone's time. Let's
> tone down the rhetoric and let developers do their jobs, now that
> they've been made aware of this critical issue.
>

Please note that it is extremely important that backports and the making of
releases containing those backports is a critical part of the process of
rectifying this issue.
It cannot be left to just resolve itself via the organic process of users
updating their systems to major versions - because that won't happen for
months or longer and it is likely that the issue will continue to intensify
before it gets any better.

Based on data we have we know that a big proportion of the traffic is
coming from KF 5.86 based systems so these patches need backporting as
distributions will not ship major version updates to these users.
Patch releases however have a chance (especially if we prod packagers) of
making their way to those users within a matter of days.

To date all mentions I have made of backports being essential have been
ignored.


>
> Nate
>

Regards,
Ben


>
>
> On 2/8/22 02:53, Jonathan Riddell wrote:
> > You'll need to take this up with the maintainers of Discover and
> > KNewStuff.  There's no reason why fixing the issue wouldn't resolve the
> > problem as fast as removing it.
> >
> > Jonathan
> >
> >
> > On Tue, 8 Feb 2022 at 06:53, Ben Cooksley  > > wrote:
> >
> > On Tue, Feb 8, 2022 at 1:12 AM Jonathan Riddell  > > wrote:
> >
> > I'm not going to publish updates that just remove an important
> > feature.  Rather there needs to be discussion in the normal KDE
> > method and that feature should be fixed.
> >
> >
> > Sorry but i'm going to categorically reject in the strongest
> > possible terms the above statement.
> >
> > What you are in essence saying is that your view is that it is
> > acceptable to conduct a distributed denial of service attack on
> > someone (even if it unintentional) and then refuse to disable the
> > functionality in question while the issue is investigated in full
> > and fixed properly.
> > That quite simply is appalling.
> >
> >
> > Jonathan
> >
> >
> > Regards,
> > Ben
> >
> >
> >
> > On Sun, 6 Feb 2022 at 18:46, Ben Cooksley  > > wrote:
> >
> > On Fri, Feb 4, 2022 at 7:52 AM Jonathan Riddell
> > mailto:j...@jriddell.org>> wrote:
> >
> > The tars for Plasma 5.24 are ready on deino for
> > packaging in distributions.  Release is due next Tuesday.
> >
> >
> > Hi Jonathan,
> >
> > I've now withdrawn these tarballs as they contain code that
> > performs a denial of service attack on KDE.org
> infrastructure.
> >
> > As this affects more than just Discover (with KWin,
> > plasma-workspace and kdeplasma-addons all containing defects
> > that are part of this series as well) a full respin of all
> > packages will be required.
> >
> > We also need patch releases of Discover for all versions
> > going back to Plasma/5.18. While I appreciate that some of
> > these are "out of support" the extraordinary nature of the
> > problem we are facing requires it to be made (much like how
> > Microsoft released a fix for Windows XP in the wake of
> Wannacry)
> >
> >
> > Jonathan
> >
> >
> > Thanks,
> > Ben
> >
>


Re: plasma 5.24 tars ready for packaging

2022-02-08 Thread Nate Graham
Much work is currently in progress to actually fix these issues. I see 
multiple merge requests across multiple repos being reviewed and merged. 
I think it makes sense to let that process happen. I see no indication 
of the issue not being taken seriously, even considering the hyperbolic 
and threatening way in which it was communicated mere days before a 
major software release that is already occupying everyone's time. Let's 
tone down the rhetoric and let developers do their jobs, now that 
they've been made aware of this critical issue.


Nate


On 2/8/22 02:53, Jonathan Riddell wrote:
You'll need to take this up with the maintainers of Discover and 
KNewStuff.  There's no reason why fixing the issue wouldn't resolve the 
problem as fast as removing it.


Jonathan


On Tue, 8 Feb 2022 at 06:53, Ben Cooksley > wrote:


On Tue, Feb 8, 2022 at 1:12 AM Jonathan Riddell mailto:j...@jriddell.org>> wrote:

I'm not going to publish updates that just remove an important
feature.  Rather there needs to be discussion in the normal KDE
method and that feature should be fixed.


Sorry but i'm going to categorically reject in the strongest
possible terms the above statement.

What you are in essence saying is that your view is that it is
acceptable to conduct a distributed denial of service attack on
someone (even if it unintentional) and then refuse to disable the
functionality in question while the issue is investigated in full
and fixed properly.
That quite simply is appalling.


Jonathan


Regards,
Ben



On Sun, 6 Feb 2022 at 18:46, Ben Cooksley mailto:bcooks...@kde.org>> wrote:

On Fri, Feb 4, 2022 at 7:52 AM Jonathan Riddell
mailto:j...@jriddell.org>> wrote:

The tars for Plasma 5.24 are ready on deino for
packaging in distributions.  Release is due next Tuesday.


Hi Jonathan,

I've now withdrawn these tarballs as they contain code that
performs a denial of service attack on KDE.org infrastructure.

As this affects more than just Discover (with KWin,
plasma-workspace and kdeplasma-addons all containing defects
that are part of this series as well) a full respin of all
packages will be required.

We also need patch releases of Discover for all versions
going back to Plasma/5.18. While I appreciate that some of
these are "out of support" the extraordinary nature of the
problem we are facing requires it to be made (much like how
Microsoft released a fix for Windows XP in the wake of Wannacry)


Jonathan


Thanks,
Ben



Re: plasma 5.24 tars ready for packaging

2022-02-08 Thread Jonathan Riddell
You'll need to take this up with the maintainers of Discover and
KNewStuff.  There's no reason why fixing the issue wouldn't resolve the
problem as fast as removing it.

Jonathan


On Tue, 8 Feb 2022 at 06:53, Ben Cooksley  wrote:

> On Tue, Feb 8, 2022 at 1:12 AM Jonathan Riddell  wrote:
>
>> I'm not going to publish updates that just remove an important feature.
>> Rather there needs to be discussion in the normal KDE method and that
>> feature should be fixed.
>>
>
> Sorry but i'm going to categorically reject in the strongest possible
> terms the above statement.
>
> What you are in essence saying is that your view is that it is acceptable
> to conduct a distributed denial of service attack on someone (even if it
> unintentional) and then refuse to disable the functionality in question
> while the issue is investigated in full and fixed properly.
> That quite simply is appalling.
>
>
>> Jonathan
>>
>
> Regards,
> Ben
>
>
>>
>>
>> On Sun, 6 Feb 2022 at 18:46, Ben Cooksley  wrote:
>>
>>> On Fri, Feb 4, 2022 at 7:52 AM Jonathan Riddell  wrote:
>>>
 The tars for Plasma 5.24 are ready on deino for packaging in
 distributions.  Release is due next Tuesday.

>>>
>>> Hi Jonathan,
>>>
>>> I've now withdrawn these tarballs as they contain code that performs a
>>> denial of service attack on KDE.org infrastructure.
>>>
>>> As this affects more than just Discover (with KWin, plasma-workspace and
>>> kdeplasma-addons all containing defects that are part of this series as
>>> well) a full respin of all packages will be required.
>>>
>>> We also need patch releases of Discover for all versions going back to
>>> Plasma/5.18. While I appreciate that some of these are "out of support" the
>>> extraordinary nature of the problem we are facing requires it to be made
>>> (much like how Microsoft released a fix for Windows XP in the wake of
>>> Wannacry)
>>>
>>>

 Jonathan


>>> Thanks,
>>> Ben
>>>
>>


Re: plasma 5.24 tars ready for packaging

2022-02-08 Thread Jonathan Riddell
A late update to Discover 5.24 tar today

discover;Plasma/5.24;84d59c60eaf4714681db0f38a935ba03e9e5f019;discover-5.24.0.tar.xz;18889fa78d00dec8b112e09a177aa286079e5946cb2f9d15c43c0c6515de6e35


On Thu, 3 Feb 2022 at 18:51, Jonathan Riddell  wrote:

> The tars for Plasma 5.24 are ready on deino for packaging in
> distributions.  Release is due next Tuesday.
>
> Jonathan
>
>


Re: plasma 5.24 tars ready for packaging

2022-02-07 Thread Ben Cooksley
On Tue, Feb 8, 2022 at 1:12 AM Jonathan Riddell  wrote:

> I'm not going to publish updates that just remove an important feature.
> Rather there needs to be discussion in the normal KDE method and that
> feature should be fixed.
>

Sorry but i'm going to categorically reject in the strongest possible terms
the above statement.

What you are in essence saying is that your view is that it is acceptable
to conduct a distributed denial of service attack on someone (even if it
unintentional) and then refuse to disable the functionality in question
while the issue is investigated in full and fixed properly.
That quite simply is appalling.


> Jonathan
>

Regards,
Ben


>
>
> On Sun, 6 Feb 2022 at 18:46, Ben Cooksley  wrote:
>
>> On Fri, Feb 4, 2022 at 7:52 AM Jonathan Riddell  wrote:
>>
>>> The tars for Plasma 5.24 are ready on deino for packaging in
>>> distributions.  Release is due next Tuesday.
>>>
>>
>> Hi Jonathan,
>>
>> I've now withdrawn these tarballs as they contain code that performs a
>> denial of service attack on KDE.org infrastructure.
>>
>> As this affects more than just Discover (with KWin, plasma-workspace and
>> kdeplasma-addons all containing defects that are part of this series as
>> well) a full respin of all packages will be required.
>>
>> We also need patch releases of Discover for all versions going back to
>> Plasma/5.18. While I appreciate that some of these are "out of support" the
>> extraordinary nature of the problem we are facing requires it to be made
>> (much like how Microsoft released a fix for Windows XP in the wake of
>> Wannacry)
>>
>>
>>>
>>> Jonathan
>>>
>>>
>> Thanks,
>> Ben
>>
>


Re: plasma 5.24 tars ready for packaging

2022-02-07 Thread Jonathan Riddell
I should note that plasma-phone-componets had a name change to
plasma-mobile.  Following discussion with packagers on chat the tars are
called plasma-mobile but there are symlinks on the server for the old names.

This was done post repo freeze, post beta and without any discussion, it
would be really appreciated if developers didn't make this sort of change
when the release schedule doesn't allow it.

Jonathan


On Thu, 3 Feb 2022 at 18:51, Jonathan Riddell  wrote:

> The tars for Plasma 5.24 are ready on deino for packaging in
> distributions.  Release is due next Tuesday.
>
> Jonathan
>
>


Re: plasma 5.24 tars ready for packaging

2022-02-07 Thread Jonathan Riddell
A second update to KWin tar for Plasma 5.24

kwin;Plasma/5.24;9e9bb6c6deaf76834340b9359d0e19fc7ccee8cd;kwin-5.24.0.tar.xz;c6aec516954c1149aba394530a52c0514b60b21f4d834f58603d648be1bd05a7


On Mon, 7 Feb 2022 at 12:11, Jonathan Riddell  wrote:

> I've published updates to kwin, plasma-workspace and kdeplasma-addons
> ahead of planned release of Plasma 5.24 tomorrow.
>
> Current commit numbers and sha256 list at
> http://embra.edinburghlinux.co.uk/~jr/tmp/5.24.0-release-data
>
> Jonathan
>
>
> On Thu, 3 Feb 2022 at 18:51, Jonathan Riddell  wrote:
>
>> The tars for Plasma 5.24 are ready on deino for packaging in
>> distributions.  Release is due next Tuesday.
>>
>> Jonathan
>>
>>


Re: plasma 5.24 tars ready for packaging

2022-02-07 Thread Jonathan Riddell
I'm not going to publish updates that just remove an important feature.
Rather there needs to be discussion in the normal KDE method and that
feature should be fixed.

Jonathan


On Sun, 6 Feb 2022 at 18:46, Ben Cooksley  wrote:

> On Fri, Feb 4, 2022 at 7:52 AM Jonathan Riddell  wrote:
>
>> The tars for Plasma 5.24 are ready on deino for packaging in
>> distributions.  Release is due next Tuesday.
>>
>
> Hi Jonathan,
>
> I've now withdrawn these tarballs as they contain code that performs a
> denial of service attack on KDE.org infrastructure.
>
> As this affects more than just Discover (with KWin, plasma-workspace and
> kdeplasma-addons all containing defects that are part of this series as
> well) a full respin of all packages will be required.
>
> We also need patch releases of Discover for all versions going back to
> Plasma/5.18. While I appreciate that some of these are "out of support" the
> extraordinary nature of the problem we are facing requires it to be made
> (much like how Microsoft released a fix for Windows XP in the wake of
> Wannacry)
>
>
>>
>> Jonathan
>>
>>
> Thanks,
> Ben
>


Re: plasma 5.24 tars ready for packaging

2022-02-07 Thread Jonathan Riddell
I've published updates to kwin, plasma-workspace and kdeplasma-addons ahead
of planned release of Plasma 5.24 tomorrow.

Current commit numbers and sha256 list at
http://embra.edinburghlinux.co.uk/~jr/tmp/5.24.0-release-data

Jonathan


On Thu, 3 Feb 2022 at 18:51, Jonathan Riddell  wrote:

> The tars for Plasma 5.24 are ready on deino for packaging in
> distributions.  Release is due next Tuesday.
>
> Jonathan
>
>


Re: plasma 5.24 tars ready for packaging

2022-02-06 Thread Ben Cooksley
On Fri, Feb 4, 2022 at 7:52 AM Jonathan Riddell  wrote:

> The tars for Plasma 5.24 are ready on deino for packaging in
> distributions.  Release is due next Tuesday.
>

Hi Jonathan,

I've now withdrawn these tarballs as they contain code that performs a
denial of service attack on KDE.org infrastructure.

As this affects more than just Discover (with KWin, plasma-workspace and
kdeplasma-addons all containing defects that are part of this series as
well) a full respin of all packages will be required.

We also need patch releases of Discover for all versions going back to
Plasma/5.18. While I appreciate that some of these are "out of support" the
extraordinary nature of the problem we are facing requires it to be made
(much like how Microsoft released a fix for Windows XP in the wake of
Wannacry)


>
> Jonathan
>
>
Thanks,
Ben


plasma 5.24 tars ready for packaging

2022-02-03 Thread Jonathan Riddell
The tars for Plasma 5.24 are ready on deino for packaging in
distributions.  Release is due next Tuesday.

Jonathan