Latest update - 2018.05.26 - missing key on CentOS

[Jan Kowalsky]

Hi all,

for debian Repos I got the same (or similar?) problem. The apt-key
https://ssl.kolabsys.com/community.asc mentioned in the kolab install
howto on https://docs.kolab.org/installation-guide/debian-8.html isn't
the key the repository is signed anymore.

This key works:
https://obs.kolabsys.com/repositories/Kolab:/16/Debian_8.0/Release.key

I haven't a clue about centos repos, but maybe there is one:
https://obs.kolabsys.com/repositories/Kolab:/16/CentOS_7/repodata/

But of course this is like pulling myself up by my own bootstraps ...

Regards
Jan

Am 15.06.2018 um 12:56 schrieb Skale, Franz:
> Hi,
> concur, but before we should have an official statement what the actual
> status is.
> A month without an official statement makes me think.
> Sure, we can setup a server and configuring reprepro and providing a
> signed package.
> I do that every day but if we start a mirror and work together, we
> should have an official statement though.
> 
> Rgds.
> Franz
>  Am 2018-06-15 10:34, schrieb Benedikt Schäfer:
>> Hey,
>>
>> I think what Enrico wanted to say is more like,
>> what could we do as community to avoid those kind of problmes in the
>> future and improve the Kolab community.
>> Maybe we could run a community infrastructure by our own, just an idea
>> to be more independent from Kolab Systems?
>>
>> Best regards,
>> Benedikt
>>
>>
>>
>> Am 15.06.2018 08:30, schrieb Christoph Erhardt:
>>> Hi Enrico,
>>>
>>> I think you may be mistaking me for a staff member of Kolab Systems;
>>> I'm just
>>> a regular member of the project's open-source community like you are.
>>> ;-)
>>>
>>> I agree with what you wrote, but I cannot do anything about it (other
>>> than
>>> help out in the areas where my progress is not dependent on somebody
>>> at Kolab
>>> Systems flicking a switch).
>>>
>>> Regarding the workaround for the signing-key issue: fortunately, it's
>>> not as
>>> problematic as you think. If you change the repository link to
>>> https://, your
>>> package manager validates the server's host certificate and downloads
>>> all
>>> packages over an encrypted connection - which should provide roughly
>>> the same
>>> level of integrity guarantees. Still, I agree that this issue should
>>> be fixed
>>> rather today than tomorrow.
>>>
>>> Best regards,
>>> Christoph
>>>
>>> On Thursday, 14 June 2018 13:46:28 CEST Enrico Tagliavini wrote:
>>>> Hello Christoph,
>>>>
>>>>      if I may throw in a suggestion, without sounding like a troll or
>>>> an hater, but rather trying to be constructive: maybe this is a good
>>>> time to review the internal priorities. I understand there is one
>>>> person only maintaining the infrastructure and I fully understand he
>>>> can be busy. Blocking updates of all users for multiple weeks should
>>>> be a very high priority task, I know there is a workaround but it
>>>> involved disabling the only check guaranteeing the source of the
>>>> package. Possibly this person needs some help if he cannot flush his
>>>> queue enough to reach the point where he can take care of this task.
>>>>
>>>> Again: this is just not to flame or troll, I support Kolab, and I
>>>> appreciate the work from everybody working on it and I want it to be
>>>> as successful as possible, that's also why I want such issue not to
>>>> happen or to be addressed timely.
>>>>
>>>> Thank you.
>>>> Kind regards.
>>>>
>>>> Enrico
>>> _______________________________________________
>>> users mailing list
>>> users at lists.kolab.org
>>> https://lists.kolab.org/mailman/listinfo/users
>> _______________________________________________
>> users mailing list
>> users at lists.kolab.org
>> https://lists.kolab.org/mailman/listinfo/users
> _______________________________________________
> users mailing list
> users at lists.kolab.org
> https://lists.kolab.org/mailman/listinfo/users