{{Header}} __FORCETOC__ {{#seo: |description=project news |image=News-574739640.jpg }} [[File:News-574739640.jpg|thumb]] {{intro| This is a draft for a new package called "project-news" which would allow projects to reliably communicate important news to users, including security issues and deprecation notices. The package would be plugin-based and available on desktops, and users could subscribe to different news channels and configure the messages they want to receive. }} __TOC__ == why == Examples when project news would have been and will be useful. * Projects don't have a reliable way to communicate with users. Reliable meaning, that 99,9% of users have a chance to actually read important news such as deprecation notices and action needed in case of security issues. ** Only a fraction of users checks news blogs first let alone rss subscribes to blogs. ** Only a fraction of users signs up to mailing lists. ** History has shown, that [[Stay Tuned]] is mostly ignored. * apt bugs * apt signing key revocation == project news == * plugin / settings based * on your desktop * cli users: local mail == apt-listchanges == Why not use apt-listchanges instead? * Too technical. * Lists changelogs, not news. * Does not work in case of apt issues. == subscription channels == * emergency news only * calls for testing * all project news * ...? == buttons == * remind me * do not show this again https://forums.whonix.org/t/do-not-show-this-message-again-generic-one-time-popup/8066 == read and process this == https://forums.whonix.org/t/apt-get-upgrading-security-issue-cve-2016-1252/3288/17 == read and process this also == https://forums.whonix.org/t/whonix-upgrade-notification/3284 == message expiration == (some) messages (configurable) should only be valid for a certain time == The Update Framework == https://theupdateframework.io/ == emergency news signing key security == The emergency notification messages should be signed with a different key than the one for repo package signing old and new. == multi sig == 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://web.archive.org/web/20221013100419/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. == /etc/emergency-news.d == The code for downloading the emergency news should be configurable. Download the emergency news files from: * version 1 - download from clearnet web servers * version 2 - optionally download from onion web servers * version 3 - optionally download from freenet / or something that implements a [[Dev/Permanent_Takedown_Attack_Defender|permanent takedown attack defense]] == distribution plugins == * Debian, Qubes, Ubuntu, {{project_name_long}} == application plugins == Should application packages be allowed to use this mechanism also? Distributions should be able to disable applications pushing news. == annoyance == Should prevent against fear of annoying spam messages on their desktops. == speak generally == Do not speak specifically about DDs since derivative distributions would handle this similarly by adding their distribution specific configuration file drop-in. == test cases == * multiple notifications at once == message format == Text only? Clickable hyperlinks? Html, oh well? Security? == project name == project-news is the proposed package name and project name. It is not fixed. We can still discuss this at {{project_name_short}} and should leave this open during publication of this concept. = Proposal = TODO: * Take any of the above bullet points one by one and convert those into a good wording that can be posted on the debian-devel mailing list.
= alternative package managers = * https://wiki.debian.org/Apt2 * https://wiki.debian.org/Cupt = Sponsors = * Should ask core infrastructure initiative once the concept is ready. = Transports = IPFS has experimental Tor support. Leaks? No big deal if yes since we use a leak proof design. https://dweb-primer.ipfs.io/avenues-for-access/tor-transport "As for preserving content, it is an explicit choice to be made by nodes and this is done by "pinning" the files otherwise new content will replace the old over time. The choice of what to keep is explicit (Freenet is exceptional in that it makes sure no one can censor the or choose the content they host) and so in theory we can pre-configure every {{project_name_short}} user as an IPFS node over Tor, but leave the choice to participate as opt-in in case they are in a part of the world with slow connections or a metered/limited connection. First it can be used to host critical announcements/news and later perhaps to share the code itself if a decapitation attack is in progress." https://medium.com/pinata/what-is-an-ipfs-pinning-service-f6ed4cd7e475 https://docs.ipfs.io/how-to/work-with-pinning-services/ https://dweb-primer.ipfs.io/files-on-ipfs/pin-files ---- I2P + Tahoe-LAFS - no public storage grid? ---- [[Freenet]] -> requires [[UDP]] ---- ZeroNet -> dependency issues ---- Users could choose their daemons to be permanently running or as intermittent connections that make brief connections every X days for a minute or 2 to check for new news files. "Would you like to keep your node always running to help make the project files resistant to censorship take-down?" = Related = * [[Dev/Permanent Takedown Attack Defender|Permanent Takedown Attack Defender, proposal to defend a permanent takedown threat]] * [[Dev/apt-revoker|apt-revoker Check for Revocation Certificates before running APT]] {{Footer}} [[Category:Development]]