[kdepim-runtime/Applications/16.12] resources/shared/singlefileresource: Fix DATA LOSS bug in ical resource which failed to create std.ics if it didn't exist.

[Ben Cooksley]

On Thu, Dec 29, 2016 at 12:14 AM, Albert Astals Cid <aacid at kde.org> wrote:
> El dissabte, 24 de desembre de 2016, a les 15:05:15 CET, Ben Cooksley va
> escriure:
>> On Sat, Dec 24, 2016 at 7:26 AM, Albert Astals Cid <aacid at kde.org> wrote:
>> > So i guess we're in agreement that we need a new tarball? Or can we just
>> > tell distro packagers to patch it?
>> >
>> > My issue with a new tarball is that i will need to call it 16.12.0.1
>> > (since i don't want to do 16.12.1 with just kderuntime-changes) and then
>> > distros are going to complain since it has one extra version, and since
>> > it's not a whole new release we again basically depend on distros picking
>> > up the new tarball.
>> Whichever one works easiest for the packagers I guess.
>>
>> Considering the severity of this issue though (silent data loss) we
>> should probably make an advisory in about a month's time of which
>> distributions have failed to patch/upgrade their packages so users are
>> aware of the risk they are taking.
>
> We only have security advisories AFAIK
> https://www.kde.org/info/security/
>
> What kind of advisory/way to make the world now were you thinking about?

A press release of some description would do the job I think.
I'll admit i'm not sure of the form it should take though.

>
> Cheers,
>   Albert

Cheers,
Ben

>
>>
>> > So may as well just ask them to patch it in?
>> >
>> > Cheers,
>> >
>> >   Albert
>>
>> Cheers,
>> Ben
>>
>> > El dimarts, 20 de desembre de 2016, a les 21:24:16 CET, David Faure va
>> >
>> > escriure:
>> >> On mardi 20 décembre 2016 10:29:03 CET Sandro Knauß wrote:
>> >> > Hey,
>> >> >
>> >> > mmh the description of your problem does not match with the commit you
>> >> > have
>> >> > pushed, or do i miss anything.
>> >>
>> >> The latter, I think ;)
>> >>
>> >> > Your patch is "only doing:
>> >> > QUrl(mSettings->path()) -> QUrl::fromUserInput(mSettings->path());
>> >> > right?
>> >>
>> >> Right.
>> >>
>> >> > that means that we still have the problem with schema prefix in the
>> >> > url?
>> >>
>> >> No, fromUserInput supports both absolute paths and URLs, see API docs.
>> >>
>> >> > And than mCurrentUrl.isLocalFile() is not true and you'll do not enter
>> >> > that
>> >> > codepath?
>> >>
>> >> isLocalFile() will be true for local files and false for remote URLs, I
>> >> don't see a problem here.
>> >>
>> >> > Just a little bit curious, why this is only a problem for a new user?
>> >>
>> >> Well, anyone without a ~/.local/share/apps/korganizer/ subdir,
>> >> which certainly includes new users.
>> >>
>> >> > On the other side I do not understand why the default local is import
>> >> > to
>> >> > trigger this bug.
>> >>
>> >> Parse error at "default local is import". Can you rephrase?
>> >>
>> >> > Btw. if the default location for korganzier has changed, than please
>> >> > update
>> >> > the defaultcalendar.desktop path.
>> >>
>> >> And break "Personal Calendar" for all users who copy their home dir (but
>> >> not their akonadi setup) to another computer? Seems too dangerous to me,
>> >> for zero gain. The korganizer in the path is historical anyhow,
>> >> korganizer no longer accesses std.ics directly, ever since akonadi 1
>> >> came into play.
>
>