aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--archive/2021-09-28-announcement-inspiration117
-rw-r--r--archive/2021-09-28-design-comments23
2 files changed, 140 insertions, 0 deletions
diff --git a/archive/2021-09-28-announcement-inspiration b/archive/2021-09-28-announcement-inspiration
new file mode 100644
index 0000000..0ab27ab
--- /dev/null
+++ b/archive/2021-09-28-announcement-inspiration
@@ -0,0 +1,117 @@
+Summary
+ * Announce via mailing list
+ * It happens in our community
+ * It makes it easy to respond
+ * It makes it easy to forward
+ * We can keep our website minimal for now (landing page)
+ * Announcements seem to be relatively short
+ * Max 500 words is probably a good rule of thumb
+ * Shorter if you have a few polished links to reference
+ * Possible points to make, also based on what we discussed before
+ * What type of project are we
+ * What is the project about
+ * What is the purpose of project announcement
+ * What is the timeline leading up to announcement
+ * What is the current project status
+ * What are the next steps
+ * Who is involved, people and funders
+ * Relevant links to help the reader navigate sigsum
+ * (Get feedback from a communicator)
+
+Other things to keep in mind
+ * Double check that what we are linking is in good enough shape
+ * E.g., small TODOs in sigsum-log-go README.md (fix links)
+ * We should think about what questions people might have in response to announcement
+ * Perhaps it would be a good idea to give design.md FAQ some love
+ * Try to avoid too much detail, we can make sigsum blog posts at a later stage
+ * The fact that we are aware of sigstore should probably be clear
+ * Let people ask, that's fine
+
+---
+Warning: I have not spent much time verifying if there were other announcements
+than the ones specified below. It is the result of a v. quick search / analysis.
+
+(Some of the below links are not even project announcements, but rather
+announcement of 'we are developing or developed cool thing XXX'. I kept
+everything I found useful as inspiration in case it helps anyone else.)
+
+Debian
+ * https://www.debian.org/doc/manuals/project-history/project-history.en.pdf
+ * See ยง1.1
+ * How: mail
+ * Points
+ * This is a work in progress
+ * It is cool because XXX
+ * Purpose of anouncement is XXX
+ * It is better than XXX because A,B,...
+
+Tails (back then amnesia)
+ * https://lists.torproject.org/pipermail/tor-talk/2009-August/002667.html
+ * How: mail
+ * Points
+ * This work is about XXX
+ * Licence is XXX
+ * Purpose of announcement is XXX
+ * We prefer if you get in touch via XXX
+
+Qubes
+ * https://blog.invisiblethings.org/2010/04/07/introducing-qubes-os.html
+ * How: post on website
+ * Points
+ * Timeline before announcing project
+ * Project is about doing XXX
+ * Current project status is XXX
+ * Learn more via resources XXX
+
+Signal
+ * https://signal.org/blog/signal/
+ * How: post on website
+ * Points
+ * Timeline leading up to announcement
+ * Mision and work is about XXX
+ * Next steps
+ * Who is involved
+ * "Give it a try!"
+
+Wireguard
+ * https://lists.zx2c4.com/pipermail/wireguard/2016-June/000002.html
+ * How: Mail
+ * Points
+ * Been at this for a while, confident enough to launch now
+ * Purpose of launch is XXX
+ * Link relevant resources (paper, website, git, mailing list)
+ * One paragraph primer (118 words)
+
+Firecracker
+ * https://aws.amazon.com/about-aws/whats-new/2018/11/firecracker-lightweight-virtualization-for-serverless-computing/
+ * How: post on website
+ * Points
+ * We are launching product XXX
+ * Key concepts are XXX
+ * How it is used / can be used
+ * Visit XXX to learn more
+
+System Transparency
+ * https://mullvad.net/en/blog/2019/6/3/system-transparency-future/
+ * How: post on website
+ * Points
+ * Key questions and background that motivated this work
+ * We believe that ST gives you the ability to XXX
+ * Call to action
+ * Little detail, link to ST white paper
+
+Sigstore
+ * How: press releases on partner websites
+ * https://security.googleblog.com/2021/03/introducing-sigstore-easy-code-signing.html
+ * Points
+ * What is the problem
+ * Announcement project with goal/mission XXX
+ * Problem space is related to XXX, involved tehniques are...
+ * Collaboration is between XXX
+ * Request for feedback
+ * Next steps
+ * https://www.linuxfoundation.org/en/press-release/linux-foundation-announces-free-sigstore-signing-service-to-confirm-origin-and-authenticity-of-software/
+ * Points
+ * Collaborators XXX want to achive XXX
+ * Quotes from involved people that explain idea and purpose
+ * Refer to website for more information
diff --git a/archive/2021-09-28-design-comments b/archive/2021-09-28-design-comments
new file mode 100644
index 0000000..42cebec
--- /dev/null
+++ b/archive/2021-09-28-design-comments
@@ -0,0 +1,23 @@
+-design.md file: [rohonk]
+
+ Line 39-49: This part is very important as it clearly states the goal of the project. Also it draws a comparison between our goal and what we want to achieve different/better than the previously available certificate transperancy. I would like to suggest if we can make a different subsection 1.2, which deals with the comparative study.
+
+ Line 60-62: Using Claimant Model.
+
+ Line 88-89: Does it mean that the fingerprint i.e. (hash of the opaque data is already stored in the sigsum log)? And now the Claimant checks with the log.
+
+ Figure 1: What happens if one of the participating party (Believer/Claimant) act maliciously by deviating from the protocol?
+
+ Line 109-113: Introduction to DNS in order to avoid log poisoning is a very interesting concept.
+
+ Line 141-158: Each of the different attack circumstances needs to be dealt with in the security proof. Here we are considering an external attacker as a threat. Is it a good question to ask that what happens when the trusted party act maliciously within the system?
+
+ Line 183-185: This part partially address my concern stated in the previous point.
+
+ Steps for Security Proof:
+ https://git.sigsum.org/sigsum/tree/archive/2021-06-21-system-overview-ascii
+ 1. Writing pseudocodes for each interaction i.e. Claimant <> Believer ,
+ Claimant <> Witness.
+ 2. Have a threat model considering all possible misbehaviours.
+ 3. Cryptographic Schemes already determined (CRH, ECDSA)
+ 4. Decide on what kind of security proof is necessary like pen and paper proof or using software like Proverif/Tamarind?