I want to help with the brainstorming for this. It will get more attention especially with the recent CVEs. This particular utility is a good candidate for Core Infrastructure funding IMO.

Removed previous comment. The task is big enough no need to bite more than we can chew.

• To avoid getting into a trust bootstrapping nightmare - its not enough to revoke a key but also send a new one via the emergency notification system to replace the revoked one. The emergency notification messages should be signed with a different key than the one for repo package signing old and new. In a sense the emergency key is a master key that should be very well guarded and only used in such situations - because it has authority over repo keys. Its sounds bad but I don't have better ideas for this.

• Should revocation be automated? IMO nothing should ever be done automatically. Fortunately apt in Whonix doesn't do automatic updates. Imagine how bad that would have been!

• The key handling/revoking should be done via GPG itself of course. We should only be concerned about the scripting that handles a remote emergency command and its execution on the machine.

• Language choice: Up to you. Whichever you are comfortable with is best unless upstream is prejudiced against one or the other for security reasons.

• I did not get the feeling that keyserver use is unwelcome however this is just one pool - there are still many other operators. Also it might be a redundancy with either centralized server-client used instead or a decentralized storage alternative. The priority is to support server-client model first because this is likely what the most common usecase will be.

HulaHoop (HulaHoop):

• To avoid getting into a trust bootstrapping nightmare - its not

enough to revoke a key but also send a new one via the emergency
notification system to replace the revoked one.

Emergency news should only inform about the new key. Not add the new
key. Otherwise that functionality would exceed the competence of
emergency news.

The emergency
notification messages should be signed with a different key than the
one for repo package signing old and new.

added here:
https://www.whonix.org/wiki/Dev/emergency-news

In a sense the emergency
key is a master key that should be very well guarded and only used in
such situations - because it has authority over repo keys. Its sounds
bad but I don't have better ideas for this.

Should use multi sig (key splitting).

The Debian apt signing key is on an official debian.org server. The
revocation key is on Debian Developer's (DD) machines. (Not necessarily
offline machines.)

They would need at least a 7/12 signature to create the Debian apt
signing key revocation certificate.

Source:
https://ftp-master.debian.org/keys.html

So by using multi sig and not keeping the the emergency news signing key
only on DD's machines, it would be safer than Debian's apt signing key.

Added here:
https://www.whonix.org/wiki/Dev/emergency-news

• Should revocation be automated? IMO nothing should ever be done

automatically. Fortunately apt in Whonix doesn't do automatic
updates. Imagine how bad that would have been!

Perhaps it should be checked for revocation certificates on every run of
apt-get update but not otherwise automated? [Unless users opted in for
auto apt updates but then that's there choice - no difference to the
current situation.]

• The key handling/revoking should be done via GPG itself of course.

We should only be concerned about the scripting that handles a remote
emergency command and its execution on the machine.

I'd advice against signing the emergency news on any official debian.org
system. That should be done be done only on demand by DDs. Does that
address your point?

• Language choice: Up to you. Whichever you are comfortable with is

best unless upstream is prejudiced against one or the other for
security reasons.

What do you mean by language choice? Do you mean the final wording of
the proposal?

I am not eager to do the clean wording of the proposals.

• I did not get the feeling that keyserver use is unwelcome however

this is just one pool - there are still many other operators. Also it
might be a redundancy with either centralized server-client used
instead or a decentralized storage alternative. The priority is to
support server-client model first because this is likely what the
most common usecase will be.

Made a note here:
https://www.whonix.org/wiki/Dev/apt-revoker

We now have two proposals.

• https://www.whonix.org/wiki/Dev/emergency-news
• https://www.whonix.org/wiki/Dev/apt-revoker

There will be some overlap.

I guess we should present only one concept at a time? Perhaps start with
apt-revoker?

(Doesn't mean we cannot already discuss/write the emergency-news
proposal. We can discuss/write any concept as thoughts are incoming.)

Perhaps it should be checked for revocation certificates on every run of apt-get update but not otherwise automated?

By "automating" it can run with apt-update even with an apt.cron setup maybe?

What do you mean by language choice?

Bash vs Python

I guess we should present only one concept at a time? Perhaps start with apt-revoker?

Yes.

There will be some overlap.

Both tools can be used together in some situations but they are very different in what they do. If this is presented clear enough the overlap in people's minds should be eliminated.

(Doesn't mean we cannot already discuss/write the emergency-news proposal. We can discuss/write any concept as thoughts are incoming.)

Right.

In T140#11042, @HulaHoop wrote:

Perhaps it should be checked for revocation certificates on every run of apt-get update but not otherwise automated?

By "automating" it can run with apt-update even with an apt.cron setup maybe?

If apt.cron runs apt-get update, then yes. apt.cron -> apt-get update -> apt-revoker -> real apt-get updating.

What do you mean by language choice?

Bash vs Python

I would leave this open.

Renamed from emergency news to project news. It does not have to be limited to emergencies if it's configureable. Users could subscribe to various channels, i.e. emergencies only, testers wanted etc.

https://www.whonix.org/wiki/Dev/project-news

Added more points:

• https://www.whonix.org/w/index.php?title=Dev%2Fproject-news&type=revision&diff=26955&oldid=26953
• https://www.whonix.org/w/index.php?title=Dev%2Fproject-news&type=revision&diff=26956&oldid=26955
• https://www.whonix.org/w/index.php?title=Dev%2Fproject-news&type=revision&diff=26959&oldid=26958

Should only distributions be allowed to drop in news plugins or application packages also?

Should only distributions be allowed to drop in news plugins or application packages also?

Applications too. Its useful when upstream wants to communicate non backwards-compatible changes. Though it would be good to make this configurable allowed/not allowed in case distros have a problem with package news not going thru them first.

Ok, added.