I guess this has been fixed as the proposed line already exists.

By the way, OBS has an unfortunate tendency to get stuck when a lot of build jobs exist - such as right now. Maybe that issue is fixed in a newer OBS version as well?

Unfortunately it doesn't. I agree that using HTTPS should mitigate the MitM risk, but I still have to explicitly mark the repository as trusted for APT to accept it.

The weakness in SHA1 is a collision risk, not an active compromise vector.

We don't support Ubuntu 14.04.

Playing around with a custom-created key (osc signkey --create home:sicherha:Testproject) still yields a repository signed with SHA1 only.

Bumping priority because I'm getting closer to providing packages for Debian Stretch.

Temporary workaround:

1. Mark repository as [trusted=yes]
2. Follow https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872543#10
3. Hope you don't get MitM'd

Current Winterfell seems to have it fixed:

Winterfell seems to use newest boot now:

OK, this is all me ;-)

Bumping cyrus-imapd didn't solve the problem, unfortunately - it got built with Perl 5.22 again.

It's just not getting rebuilt automatically. Let's bump something and therefore trigger a rebuild, so that existing installations receive an update too (now possibly preventing an unstable system from being updated to a stable system).

Assigning to Jeroen. (Are there any others who also take care of the OBS?)

Done.

Looks like some manual interaction is necessary:
https://en.opensuse.org/openSUSE:Build_Service_Tips_and_Tricks#Removing_disabled_but_built_packages_from_a_repository

This problem seems to be fixed; I can no longer reproduce it.

From what I see Debian/testing (stretch) contains a newer phantomjs:

In T1057#15236, @sicherha wrote:

To support Trusty, we'll need a custom init script. For the other distros, we can use the existing systemd .service file.

To support Trusty, we'll need a custom init script. For the other distros, we can use the existing systemd .service file.