diff --git a/Makefile b/Makefile index adef499..0ce51cb 100644 --- a/Makefile +++ b/Makefile @@ -9,7 +9,5 @@ regenerate: publish: .v/bin/pelican -s publishconf.py - echo "blog.notmyidea.org" > output/CNAME - rsync -qazP output/. notmyidea:blog.notmyidea.org/ git push diff --git a/content/code/2025-01-23-cosign-verify-signatures.md b/content/code/2025-01-23-cosign-verify-signatures.md new file mode 100644 index 0000000..983dd6e --- /dev/null +++ b/content/code/2025-01-23-cosign-verify-signatures.md @@ -0,0 +1,80 @@ +--- +title: How to verify downloaded cosign signatures +tags: cosign, images, containers +--- + +We're currently working on a way to update the containers we're using for [Dangerzone](https://dangerzone.rocks) without having to issue new releases. + +In order to do that, we push new container images to a container registry, and sign them with an hardware key. + +In addition, we want to do the verification part without issuing HTTP requests, to avoid leaking the fact we're doing the check. + +Signing the image is pretty straighforward, but verifying wasn't. There are tools for this but they mainly expect you're online and its okay to make network requests. + +## Signing the image + +In order to use `--sk`, you need to compile your own version of `cosign`, which adds suport for hardware keys. + +```bash +git clone https://github.com/sigstore/cosign.git +cd cosign +make cosign-pivkey-pkcs11key +``` + +Then, initialize the key.: + +```bash +cosign piv-tool generate-key +# Or in case you want to disable the "touch" requirement +cosign piv-tool generate-key --touch-policy=never +``` + +And sign: + +```bash +docker login +./cosign sign --sk ghcr.io/almet/dangerzone/dangerzone@sha256:fa948726aac29a6ac49f01ec8fbbac18522b35b2491fdf716236a0b3502a2ca7 +``` + +You might also need the public key handy. Here is how to get it: + +```bash +./dev/cosign/cosign public-key --sk > pub.key +``` + +## Verifying the signature + +First, download the signatures locally and store them in `signature.json` + +```bash +cosign download signature ghcr.io/almet/dangerzone/dangerzone@sha256:fa948726aac29a6ac49f01ec8fbbac18522b35b2491fdf716236a0b3502a2ca7 > signatures.json +``` + +Then, we will need to extract the information from this `signatures.json` file, and verify it in two different ways: + +Either just check the signature against the payload, but bear in mind this won't do all the bells and whistles that come with sigstore / cosign. It will just verify that the signature matches the provided key. + +```bash +# Extract the payload and the signature +cat signatures.json | tail -1 | jq -r .Base64Signature | base64 -d > signature +cat signatures.json | tail -1 | jq -r .Payload | base64 -d > payload + +# Then, verify it with openssl +openssl dgst -sha256 -verify pub.key -signature signature payload + +# Or with cosign +cosign verify-blob --key pub.key -signature signature payload +``` + +If you want (and you probably do) to verify the signature for the payload, the signed entry timestamp for rekor and the integrity of the rest of the properties (Sigstore SET), we will need to convert some of the keys to match the expected ones, and then invoke cosign: + +```bash +# Convert the signature to a format known by --bundle +cat signatures.json | tail -1 | jq -r .Payload | base64 -d > payload +cat signatures.json | tail -1 | jq '{base64Signature: .Base64Signature, Payload, cert: .Cert, chain: .Chain, rekorBundle: {SignedEntryTimestamp: .Bundle.SignedEntryTimestamp, Payload: {body: .Bundle.Payload.body, integratedTime: .Bundle.Payload.integratedTime, logIndex: .Bundle.Payload.logIndex, logID: .Bundle.Payload.logID}}, RFC3161Timestamp}' > bundle.json + +# And then use it when verifying +cosign verify-blob --key pub.key --bundle bundle.json payload +``` + +And :tada:, we've verified the signature offline! diff --git a/content/pages/worklog/dangerzone.md b/content/pages/worklog/dangerzone.md index 8ad4a81..d5eab5b 100644 --- a/content/pages/worklog/dangerzone.md +++ b/content/pages/worklog/dangerzone.md @@ -4,6 +4,260 @@ save_as: dangerzone/index.html template: worklog-en --- +## Mercredi 09 Avril 2025 + +- [x] Blogpost preparation +- [x] Update release notes +- [ ] Update .deb PR +- [ ] Blog redesign PR +- [ ] Post-release update links +## Mardi 08 Avril 2025 (6h, 4/5) + +This was (almost) release day. We did the following: +- Met with Alex to decide what's left to do and how to organize around these tasks +- Prepare a guide to enable Podman Desktop on Windows and macOS +- Prepare and send DZ release notes to editorial + +Then we tested the `doit` script that automates the creation of the release assets in parallel, and
 it worked like a charm (down to ~2h from tag to release-ready) +## Lundi 7 Avril 2025 (8h, 5/5) + +After a sync with Alex on the release tasks, I did some QA testing for macOS where I found that an issue we thought was fixed wasn't, so I fixed it again, then I reviewed the QA-related fixes, updated the website wit the latest design changes, prepared the release notes and started making changes to the way we notify users of outdated Docker Desktop installations. +## Mercredi 02 Avril 2025 (2h, 1/5) +## Mardi 01 Avril 2025 (1h, 1/5) + +## Lundi 31 Mars 2025 (7h, 2/5) + +I woke up sick, and I'm feeling a bit off. + +- Sync with Alex, organizing how we'll tag and release. +- Some more work on the podman desktop integration, and then merged it. +- Updated the website design proposal +- Review pre-release PR by Alex + +## Vendredi 28 Mars 2025 (3h, 5/5) + +(No notes), some work on the settings, to support container runtime + +## Jeudi 27 Mars 2025 (5h, 5/5) + +- Proposed [some changes on the website](https://github.com/freedomofpress/dangerzone.rocks/pull/69). Mostly colors and fonts changes +- Upgraded our mac mini m1 to the latest macOS release, trying to install Docker Desktop without errors (the upgrade worked, but I failed to install Docker Desktop there) +- Follow-up discussion with Alex on adding Podman Desktop support + +## Mercredi 26 Mars 2025 (7h, 5/5) + +- Sync with Alex on the next steps before the release. +- Updated [our Docker cli related issue](https://github.com/freedomofpress/dangerzone/issues/1101) with a fix, while waiting for Docker Desktop to be released. +- Merged [detection of regressions in PDF generation](https://github.com/freedomofpress/dangerzone/pull/1089) +- Merged [documents OS support](https://github.com/freedomofpress/dangerzone/pull/1099) +- Had a look at what's blocking the migration to uv, [opened a draft PR about it](https://github.com/freedomofpress/dangerzone/pull/1114) + +## Mardi 25 Mars 2025 (6h, 5/5) + +- Some refactoring around `get_runtime` and `get_runtime_name` which are now wrapped into a `Runtime` class with `name` and `path` properties. +- Started putting the docs together with Sphinx, as an attempt to fix multiple documentation related bugs we've had in the past. + +## Lundi 24 Mars 2025 (5h, 5/5) + +- Follow up on the Docker Desktop bug. It's not only happening on macOS, I've been able to reproduce on Linux. They issued a fix, that was quick! +- Some work to allow the use of Podman Desktop rather than Docker Desktop (or actually any other container runtime). I went down the rabbit hole of changing how the settings are implemented, and wanted for some time to use a global rather than attaching the settings to the `dangerzone` object, but actually changed direction when realizing this would make it harder to run the tests in parallel. [A PR is out](https://github.com/freedomofpress/dangerzone/pull/1110). + +## Vendredi 21 Mars 2025 (5h, 5/5) + +No notes. Started working on reworking how we use `pathlib.Path` and removed the dependency to `dangerzone` from the settings module, in preparation for Docker Desktop support on macOS. + +## Jeudi 20 Mars 2025 (6h, 5/5) + +Spent some time looking at the still-opened PRs, updating the code whenever that's needed and adding some more feedback when needed. + +Then tagged an updated version of 0.8.1 with a README fix (the installation docs weren't working), 1:1 with Harris, and attended the biweekly team meeting, where we discussed mitigations for our macOS Docker Desktop bug, in case the fix is not timely. +## Mercredi 19 Mars 2025 (7h, 5/5) + +Some more exploration, trying to chase the conversion bug that only happens on macOS 15.2+. We try a number of different dead ends, and then start writing a minimal example of something that fails. We manage to do it, and [report a bug](https://github.com/docker/for-mac/issues/7632) on the Docker Desktop for mac repository. + +We continue trying to find the real cause of the problem, without luck. One way to solve it might be to move away from Docker Desktop, which is closed source and is another path to maintain. We could just use Podman Desktop for everything! But probably that's for another day ;-) + +## Mardi 18 Mars 2025 (8h, 5/5) + +I start the day by doing some reviews and I move on to try to reproduce an error that only happens on macOS. I start by upgrading Docker and looking for differences between the logs Erik provided and mine. + +Upgrading the operating system to the macOS Sequoia `15.3.2` makes me reproduce the error with the latest release of Dangerzone (`0.8.1`), when OCR is turned on, due to a difference between the number of bytes expected and the number of bytes received from the container process. + +I'm also able to reproduce locally on the `main` branch. Then we do a joint debugging session with Alex, trying to find the curlprit, without luck but we tried the following things, and are making progress: + +- The problem is not inside the container, as all the output is sent there. +- It seems that the process is killed at the time we read its buffer, which might be the reason why it's truncated. +- The bug is not happening when we switch to Podman as a container runtime +## Lundi 17 Mars 2025 (4h, 5/5) + +Started the day looking at Eric issues, mentioning that the documentation is not pointing to the right place for macOS and Windows, for the 0.8.1 release, and another one where the conversion actually fails. + +I've not been able to reproduce this yet (I will tomorrow), but I believe we've found a fix could be calling `multiprocessing.freeze_support()` to avoid multiprocessing to pass options to dangerzone thinking it's python, when spawning new threads. + +We've also synced with Alex, discussing what's left on the stack before the release. + +## Vendredi 14 Mars 2025 (1h, 5/5) + +I start working on putting together the documentation with Sphinx, basing the work upon what's been done by SecureDrop. +## Mercredi 12 Mars 2025 (2h, 5/5) + +I have a look at the open pull requests and make comments on them. I follow up on some questions. +## Mardi 11 Mars 2025 (3h, 5/5) + +Some feedback and discussion, and some more work on the PDF diffing, trying it out with the old reference versions. + +It's working, I update the pull request. +## Lundi 10 Mars 2025 (8h, 4/5) + +Starting the week with a sync with Alex where we discussed quickly about our feedback from the meeting from last week, did a general check-up and discussed how we will work for the upcoming release. + +I then resumed on the work on diff-pdfs. I took a look at the [diff-pdf-visually](https://github.com/bgeron/diff-pdf-visually) tool, which proposes a python API which would be convenient in our case, but doesn't really cut it since it doesn't really provide a diff, even if the library name leaves you thinking it is. So diff-pdf + +diff-pdf would be hard to package, and we probably don't want to depend on a tool that isn't packaged for debian, so, inspired by some github issue where an user is trying to do the same thing, I expended a bit. + +Doing the comparison bit by bit using python, iterating on each pixel is unfortunately reaaaally slow, see: + +``` +diff took 5.094218431997433 seconds +diff took 3.1553626069980965 seconds +diff took 3.3721952960004273 seconds +diff took 3.2134646750018874 seconds +diff took 3.3410625500000606 seconds +diff took 3.2893160990024626 seconds +``` + +So, I adapted the code to run with numpy, here are the comparison times: +``` +diff took 0.13705662599750212 seconds +diff took 0.05698924000171246 seconds +diff took 0.15319590600120137 seconds +diff took 0.06126453700198908 seconds +diff took 0.12916332699751365 seconds +diff took 0.05839455900058965 seconds +``` + +Then I took some time to discuss with Erik for some feedback. I also went back to the 0.8.1 release and regenerated the reference documents we're using, to see how they would show in the diff tool I've made. + +I also added a new flag for `pytest` that make it possible to regenerate the reference docs. + +I also spent some time reading the answers by Alex to the PR we're currently working on, for container reproducibility, and gave a green light. +## Jeudi 06 Mars 2025 (6h, 5/5) + +Most of the day was used to work on the strategic plan meeting: gathering my thoughts, giving me some space to think about what should be the future for Dangerzone in the two years to come and attending to the meeting. + +The strategic plan meeting was actually pretty good, given the fact we were around 20 people in the call, writing at the same time and sharing our thoughts. Pretty excited about the idea of doing something useful on mobile for Dangerzone in the future, and a nice way to have a peek at what's in everybody's brains. + +I also met quickly with Harris to discuss on general progress and worked a small bit on PDF diffing, saving the PDF diffs in a specific folder to explore them afterwards. + +I also answered questions and follow-ups on the container reproducibility pull request. + +## Mercredi 05 Mars 2025 (6h, 4/5) + +Started the day by syncing with Alex, where we discussed in preparation of the strategy meeting tomorrow, and planned the upcoming release. It was interesting to see we share some of the same ideas around dangerzone, and had some that stands out. + +I then [started working on PDF diffing](https://github.com/freedomofpress/dangerzone/pull/1089), with the end goal of having a way to detect regressions. I did that with a simple "compare buffers" approach to start with, but I believe what we'll likely need is a way to tell if the changes we see are actual regressions or if they are "okay". + +I tried to see the differences between the 0.8.1 release and the latest code, and that produced a slightly different document. I think it's acceptable, so the whole story is about how to make this a nice developer experience. +## Mardi 04 Mars 2025 (8h, 5/5) + +Second day on this coworking space, which seem to be a good match so far. + +I've started they day by doing a review of the reproducibility script that Alex wrote. I still find it a bit awkward that we're using `click` for some tools and `argparse` for others, but other than that it's nice to see we have a way to reproduce the containers, and check for regressions. + +Then, I started to do some brainstorming, to find what I think should be interesting in the future for Dangerzone and for Whistle-blowing platforms in general. I went for now in "full brainstorm", with the goal of finding ideas that might be useful in general. + +Then, I resumed on the quest to find a way to have an archive format that's able to retain the metadata (really, the manifest digest that we sign) for both Podman and Docker. I haven't find anything but I tried a lot of different options (podman/docker export/import, crane pull, regctl). + +The content of the layers is here, but the actual digest differs in the end, making it impossible to ensure that we're running what we think we should be. + +Maybe the signatures contain some more information, and we can check on the different layers? đŸ€” I find it weird that nobody already has something that does this. Are we the first ones to try to install containers out-of-band ? Maybe cosign has a tool to do this? + +Finishing the day with a 1:1 with Erik, where I mentioned that I'm a bit bored at times. He mentioned a few things that might be interesting: having more experimentation (but keeping them as such), an idea of a project to visualize the evolution of the size of our image over time. + +I also mentioned the fact it might be interesting to start doing some meetups around privacy around here, like we used to do with the "cryptoclub" (before crypto was money, heh). +## Lundi 03 Mars 2025 (9h, 5/5) + +Today I was in Rennes, in [a co-working space](https://www.bigrelieu-coop.fr/) I want to try out. It was a nice first day. + +Continuing the work on independent container updates, I've been adding a graphical interface for letting the users know what happen when pulling an image from a registry. I have considered different ways of doing it, but in the end didn't found a nice way to show the progress bars. + +Then, I started working on making changes to the branch in order to have the tests pass locally and on the CI. I finally put that on hold since I believe it's blocked by the creation and publishing of new images, which is provided by the work done by Alex. + +Into other things, I believe we'll need to publish the images somewhere so the tests run. I'm wondering if [ttl.sh](ttl.sh) might be a good place for this. + +Finally, I jumped into the docker/podman situation, [regarding the air-gapped archives we have](https://github.com/freedomofpress/dangerzone/issues/1068), that we are not able to load via docker (`docker load -i` expects a different format). I believe one of the way to solve this is to use a tool to do the conversion for us. [`regctl`](https://github.com/regclient/regclient/tree/main) (that I've been able to use for other matters) seem to provide that, but I've yet to make it work properly. + +It doesn't seem possible to load multi-arch container tarballs, so we might need to change how we do this, not sure yet how. + +## Vendredi 28 FĂ©vrier 2025 (4h, 5/5) + +Continuing the focus on independent container updates, I've changed the way the current mechanism work for + +## Jeudi 27 FĂ©vrier 2025 (7h, 5/5) + +Continuing the focus on independent container updates, I've changed the way the current mechanism work for update checks and notifications, making a clear separation between the GUI code and the actual checks, and updated the tests accordingly. +## Mercredi 26 FĂ©vrier 2025 (7h, 4/5) + +- Discussion w/ G_iulio and A_lex about how to handle an external contributor proposition +- Sync and discussion w/ A_lex on the current status of ICUs +- Some more tests writings, all passing now +- Updating the ICU PR, integrating review comments +- Started making changes in the GUI, prompting user about upcoming sandbox updates; started with a simplification of the actual code base. + +## Lundi 24 FĂ©vrier 2025 (4h, 2/5) + +General catch-up with Alex, discussion on why we found out a buggy release for our Fedora packages. + +I spent some time investigating security-related feature proposed by a user, to avoid having sections of memory which would be read+write +## Jeudi 13 FĂ©vrier 2025 (8h, 5/5) + +- Meeting with Tails folks to discuss their needs for inclusion in Tails, and inclusion in Debian upstream. We'll probably aiming for inclusion in `contrib` and distribute the containers in container registries and mirrors. +- Some more work on the unit-tests for independent container updates. +- Bi-weekly dangerzone team meeting, where we covered UX decisions for independent container updates, Debian upstreaming and we decided on a support matrix! +## Mercredi 12 FĂ©vrier 2025 (5h, 3/5) + +- Adding unit tests to the independent container updates +- Sync w/ Alex +## Mardi 11 FĂ©vrier 2025 (6h, 2/5) + +Yesterday and today were some more polishing on the independent container updates, discussions about security channels, and all team meeting! +## Lundi 10 FĂ©vrier 2025 (4h, 2/5) + +## Jeudi 06 FĂ©vrier 2025 (9h, 5/5) + +Preparation for the demonstration of independent container updates, with the creation [of a small presentation](https://github.com/almet/slides/blob/master/2025-02-06-dangerzone-container-updates/slides.pdf) . + +A short pairing session with Alex, trying to make multi-arch reproducibility work for containers, but we didn't have enough time to find the curlprit. + +Quick 1:1 with Harris, and then the presentation itself. + +## Mercredi 05 FĂ©vrier 2025 (7h, 4/5) + +Continued the work on independent container updates, plus some research on Debian packaging. I'm now able to see the DZ software auto-update to a new container image, verifying the signatures in the process đŸ„ł I removed the use of `image-id.txt` as a reference in the process. + +I started to prepare for the demo tomorrow, where we want to reproduce the container images as part of the demo. I added the ability to get the diffoci binary for different platforms (was only amd64 until now), and that's where I'll resume tomorrow. +## Mardi 04 FĂ©vrier 2025 (8h, 5/5) + +Polished `dangerzone-image` code, fixing some issues and ensuring that signatures stored one way could be loaded the other. + +We then synced with Alex, and paired to incorporate the work for multi-architectures, signing and verifying an image with `cosign` was a blast, but changes need to be done for airgapped archives. + +I also planned a discussion on Dangerzone debian packaging with intrigeri (from Tails) +## Lundi 03 FĂ©vrier 2025 (11h, 5/5) + +A long fun day of implementation work! + +The focus was on airgapped environments, for which I wanted to have a way to load the container images. I checked the different format provided by `podman save`, but these ones wouldn't retain the container digest across loads. I finally decided on following the `oci-image` format, which also is the one provided by `cosign save`. + +I now have an implementation locally that's able to load on another host the archive produced by `cosign save | tar cvf`. Part of the process was to extract signatures, converting them from one format to another. + +## Mercredi 15 Janvier 2025 (7h, 5/5) + +- Some more discussion w/ Alex on how to ship independent container updates. We're trying to find ways to minimize the amount of manual steps for new container updates. +- Another round of review on the reproducible builds PR +- A look into why our build instructions were failing on debian trixie. Turns out `apt-secure` is now relying on `sqv` by default, which doesn't like binary PGP keys. Turning them into base64 versions fixed the issue. Still reading a bit on the subject to see if there are ways to configure it somehow. +- Proposed a PR to remove F39 from our nightly installation tests. +- A nice walk under the sun ! ☀ ## Mardi 24 DĂ©cembre 2024 (6h, 3/5) diff --git a/content/pages/worklog/umap.md b/content/pages/worklog/umap.md index be53648..8ae3796 100644 --- a/content/pages/worklog/umap.md +++ b/content/pages/worklog/umap.md @@ -4,36 +4,19 @@ save_as: umap/index.html template: worklog total_days: 78 --- -Total prĂ©vu sur uMap pour moi = 90 jours (y compris le mĂ©cĂ©nat de Scopyleft) -NLNet = 40 000€ = 62 jours -Fait = 87 jours. - -MAIS: pas terminĂ© le travail, il manque: - -a. Scale things up: -- Throttling: frequency of sync: ability to send messages by batches -- Handle running multiple processes to handle more load, distribute the load on different WebSocket workers. -- Deal with maximum number of peers connected (what happens when the limit is met?) -b. Handle security: -- Find a mechanism to revoke permissions when the owner changes them -- Deal with an evil client sending messages to an elevated client. -- Process external security review - -Ce qui reprĂ©sente 8000€ restant Ă  payer de la part de NLNet pour: -8000€ = 12 jours (en moins) - -- Actuellement: 61h de « non payĂ© » = 5 664€ (Ă  la fin de cette semaine) = 9j - -Deux sujets: - -- Comment est-ce qu'on termine ma « mission » ? -- Des sous ont Ă©tĂ© mis de cĂŽtĂ© (par Scopyleft ? Par David ?) plus tĂŽt, qu'il n'a pas consommĂ©, et il proposait de les utiliser ici. +## Vendredi 14 Mars 2025 (0h, 3/5, 6h) +On creuse un peu sur le undo/redo pour se rendre compte que ça pourrait remplacer le SavingManager qui est actuellement utilisĂ©, pour se rendre compte que le fil Ă  tirer serait potentiellement trop long. +Je fais des changements pour faire en sorte que l'image Docker utilise Redis et permette la synchronisation. On retrouve David pour discuter de ça et de la rĂ©partition des sous. +## Jeudi 13 Mars 2025 (0h, 4/5, 7h) +On se retrouve avec Ybon pour travailler depuis les bureaux Ă  Paris. On commence Ă  parler de faire un undo / redo en utilisant les opĂ©rations qui sont envoyĂ©es via le sync. On termine par une session de dĂ©monstration du sync lors d'un "Ask Me Anything" et il n'y a pas de bug. Incroyable. +## Mercredi 12 Mars 2025 (0h, 5/5, 5h) +On se retrouve avec Yohan, on travaille sur la rĂ©solution d'un souci de fichier qui n'a pas le bon nom sur la prod. On fait un tour rapide des changements qui ont Ă©tĂ© faits depuis Novembre, c'est chouette de voir l'Ă©volution. On mange avec Virgile le midi puis on file Ă  Grizy. ## Mardi 12 Novembre 2024 (3h, 5/5) diff --git a/content/recettes/Desserts/Tarte Chocolat-Poire.md b/content/recettes/Desserts/Tarte Chocolat-Poire.md index 9c527fd..fd89007 100644 --- a/content/recettes/Desserts/Tarte Chocolat-Poire.md +++ b/content/recettes/Desserts/Tarte Chocolat-Poire.md @@ -1,6 +1,6 @@ Une de mes prĂ©fĂ©rĂ©es :-) -- 200g de poires +- 200g de poires au sirop (poids sans le liquide) - 200g de chocolat - 30cl crĂšme liquide (soja ou lait) - 1 Ɠuf @@ -11,9 +11,9 @@ Une de mes prĂ©fĂ©rĂ©es :-) --- 1. Four Ă  220°C -2. Chocolat au bain marie + la moitiĂ© de la crĂšme +2. Chocolat au bain marie (au four, pendant qu'il chauffe !) + la moitiĂ© de la crĂšme 3. Napper le fond de la pĂąte avec chocolat 4. MĂ©langer le reste de la crĂšme avec l'Ɠuf, la poudre d'amandes et le sucre -5. Le dĂ©poser par dessus le chocolat -6. Poser les poires par dessus, les dĂ©couper en fines lamelles avant la dĂ©pose (c'est plus simple). +5. Le dĂ©poser par-dessus le chocolat +6. DĂ©couper les poires en fines lamelles puis les dĂ©poser sur la tarte. 7. Enfourner jusqu'Ă  ce que le dessus change de couleur (40mn?) diff --git a/mnmlist/templates/worklog-en.html b/mnmlist/templates/worklog-en.html index 7ade026..2f4ad36 100644 --- a/mnmlist/templates/worklog-en.html +++ b/mnmlist/templates/worklog-en.html @@ -68,13 +68,13 @@ "field": "series", "scale": { "domain": ["Worked"], - "range": ["#1f77b4"] + "range": ["purple"] } } } }, { - "mark": "line", + "mark": "circle", "encoding": { "x": { "timeUnit": {"unit": "", "utc": true}, @@ -86,7 +86,7 @@ "scale": {"reverse": true} // Reverse only the y-axis for happiness }, "color": { - "value": "green" + "value": "black" } } } diff --git a/publishconf.py b/publishconf.py index dd31dac..86c494a 100644 --- a/publishconf.py +++ b/publishconf.py @@ -7,13 +7,14 @@ from __future__ import unicode_literals import os import sys + sys.path.append(os.curdir) from pelicanconf import * # NoQA -SITEURL = 'https://blog.notmyidea.org' +SITEURL = "https://notmyidea.org" RELATIVE_URLS = False -FEED_ALL_ATOM = 'feeds/all.atom.xml' -CATEGORY_FEED_ATOM = 'feeds/{slug}.atom.xml' +FEED_ALL_ATOM = "feeds/all.atom.xml" +CATEGORY_FEED_ATOM = "feeds/{slug}.atom.xml" DELETE_OUTPUT_DIRECTORY = True