Shirish Agarwal: Ayisha, Manju Warrier, Debutsav, Books
But I m drifting from the topic/movie. 
Like each month, have a look at the work funded by Freexian s Debian LTS offering.
[Note: the original version of this post named the author of the referenced blog post, and the tone of my writing could be construed to be mocking or otherwise belittling them.
While that was not my intention, I recognise that was a possible interpretation, and I have revised this post to remove identifying information and try to neutralise the tone.
On the other hand, I have kept the identifying details of the domain involved, as there are entirely legitimate security concerns that result from the issues discussed in this post.]
I have spoken before about why it is tricky to redact private keys.
Although that post demonstrated a real-world, presumably-used-in-the-wild private key, I ve been made aware of commentary along the lines of this representative sample:
I find it hard to believe that anyone would take their actual production key and redact it for documentation. Does the author have evidence of this in practice, or did they see example keys and assume they were redacted production keys?Well, buckle up, because today s post is another real-world case study, with rather higher stakes than the previous example.
xs.
Based on the steps I explained previously, it is relatively straightforward to retrieve the entire, intact private key.
72bef096997ec59a671d540d75bd1926363b2097eb9fe10220b2654b1f665b54
Searching for certificates which use that key fingerprint, we find one result: a certificate for hiltonhotels.jp (and a bunch of other, related, domains, as subjectAltNames).
As of the time of writing, that certificate is not marked as revoked, and appears to be the same certificate that is currently presented to visitors of that site.
This is, shall we say, not great.
Anyone in possession of this private key which, I should emphasise, has presumably been public information since the post s publication date of February 2023 has the ability to completely transparently impersonate the sites listed in that certificate.
That would provide an attacker with the ability to capture any data a user entered, such as personal information, passwords, or payment details, and also modify what the user s browser received, including injecting malware or other unpleasantness.
In short, no good deed goes unpunished, and this attempt to educate the world at large about the benefits of secure key storage has instead published private key material.
Remember, kids: friends don t let friends post redacted private keys to the Internet.
Contributing to Debian
is part of Freexian s mission. This article
covers the latest achievements of Freexian and their collaborators. All of this
is made possible by organizations subscribing to our
Long Term Support contracts and
consulting services.
Debian (I might as well say "we", this is the beauty of it) is about to release Debian 12 aka Bookworm. Let's take a quick look at what is new in Debian Qt land.
Qt 5
Bookworm has Qt 5.15.8, which is nothing but great news. KDE will be switching to Qt 6 sooner than later and Qt 5 has been a fun ride, but Dmitry Shachnev and I needed a break, or at very least not handling two Qt versions. But in the end I need to be fair: you REALLY need to thank Dmitry for Qt 5. He has been the man power behind it in 99.5% of the cases.
Qt 6
This will be the first Debian release to have official Qt 6 packages. NOTHING would have happened if it weren't for Patrick "Delta-One" Franz standing up to maintain it. BIG kudos to him!
Well, there is a "little lie" in the paragraph above. Thanks to The Qt Company and ICS the current Qt 6 version, 6.4.2, is also available as Bullseye's backports. The Qt Company really also helped us here by providing us almost-to-be-released tarballs of Qt 6.4.2 so we were able to push them to unstable and do a transition in time for freeze, thanks a lot for that!
So, what is the Qt 6 state?
At the binary side all but OpenGL ES support should be there. Sadly this was discovered too late in the release process and we still might need help maintaining it (read the link to know why!).
We are still not building the documentation. Properly building the whole documentation, as with Qt 5, would require all the Qt submodules' source code in one place, which we can't (easily?) do in Debian. So building the doc means hacking the build system and getting semi-linked documentation, much like with Qt 5. Now if you think you have an idea to solve this... we are happy to hear from you!
Another great thing to know about Qt 6 is that, thanks to Helmut Grohne, pure Qt 6 applications should be able to cross compile. Applications using multi-arch enabled libraries ought to work too. Even more, many Qt submodules themselves should also cross compile! Not all of them, as we missed some patches in time, but hey, if you need to cross compile Qt, you surely can apply them yourselves!
And finally tests, unit tests. In Qt 5 we had some of those, but none yet in Qt 6. This is one of the areas I would love to be able to put time... but time is scarce.
The future?
In my point of view the Debian 13 "Trixie" development cycle will see Qt 5 diminishing it's usage and Qt 6 becoming the major Qt version used, but from the Qt 4 experience I do not expect Qt 5 being dropped during this release cycle... let's see what the future brings us.
Thanks!
While I mentioned Dmitry and Patrick many more people helped us reach this place. I personally want to thank the people behind the KDE software, both upstream and, of course, the Debian maintainers. You should be thankful with them too, many hours of effort go into this.
And thanks to you our dear users. We are normally overflowed with what we have in our hands and might not be up to the task sometimes, but hey, you are part of the reason we are doing this!
Just a few days back we came to know about the horrific Train Crash that happened in Odisha (Orissa). There are some things that are known and somethings that can be inferred by observance. Sadly, it seems the incident is going to be covered up . Some of the facts that have not been contested in the public domain are that there were three lines. One loop line on which the Goods Train was standing and there was an up and a down line. So three lines were there. Apparently, the signalling system and the inter-locking system had issues as highlighted by an official about a month back. That letter, thankfully is in the public domain and I have downloaded it as well. It s a letter that goes to 4 pages. The RW is incensed that the letter got leaked and is in public domain. They are blaming everyone and espousing conspiracy theories rather than taking the minister to task. Incidentally, the Minister has three ministries that he currently holds. Ministry of Communication, Ministry of Electronics and Information Technology (MEIT), and Railways Ministry. Each Ministry in itself is important and has revenues of more than 6 lakh crore rupees. How he is able to do justice to all the three ministries is beyond me
The other thing is funds both for safety and relaying of tracks has been either not sanctioned or unutilized. In fact, CAG and the Railway Brass had shared how derailments have increased and unfulfilled vacancies but they were given no importance In fact, not talking about safety in the recently held Chintan Shivir (brainstorming session) tells you how much the Govt. is serious about safety. In fact, most of the programme was on high speed rail which is a white elephant. I have shared a whitepaper done by RW in the U.S. that tells how high-speed rail doesn t make economic sense. And that is an economy that is 20 times + the Indian Economy. Even the Chinese are stopping with HSR as it doesn t make economic sense.
Incidentally, Air Fares again went up 200% yesterday. Somebody shared in the region of 20k + for an Air ticket from their place to Bangalore
Coming back to the story itself. the Goods Train was on the loopline. Some say it was a little bit on the outer, some say otherwise, but it is established that it was on the loopline. This is standard behavior on and around Railway Stations around the world. Whether it was in the Inner or Outer doesn t make much of a difference with what happened next. The first train that collided with the goods train was the 12864 (SMVB-HWH) Yashwantpur Howrah Express and got derailed on to the next track where from the opposite direction 12841 (Shalimar- Bangalore) Coramandel Express was coming. Now they have said that around 300 people have died and that seems to be part of the cover-up. Both the trains are long trains, having between 23 odd coaches each. Even if you have reserved tickets you have 80 odd people in a coach and usually in most of these trains, it is at least double of that. Lot of money goes to TC and then above (Corruption). The Railway fares have gone up enormously but that s a question for perhaps another time . So at the very least, we could be looking at more than 1000 people having died. The numbers are being under-reported so that nobody has to take responsibility. The Railways itself has told that it is unable to identify 80% of the people who have died. This means that 80% were unreserved ticket holders or a majority of them. There have been disturbing images as how bodies have been flung over on tractors and whatnot to be either buried or cremated without a thought. We are in peak summer season so bodies will start to rot within 24-48 hours No arrangements made to cool the bodies and take some information and identifying marks or whatever. The whole thing being done in a very callous manner, not giving dignity to even those who have died for no fault of their own. The dissent note also tells that a cover-up is also in the picture. Apparently, India doesn t have nor does it feel to have a need for something like the NTSB that the U.S. used when it hauled both the plane manufacturer (Boeing) and the FAA when the 737 Max went down due to improper data collection and sharing of data with pilots. And with no accountability being fixed to Minister or any of the senior staff, a small junior staff person may be fired. Perhaps the same official that actually told them about the signal failures almost 3 months back
There were and are also some reports that some jugaadu /temporary fixes were applied to signalling and inter-locking just before this incident happened. I do not know nor confirm one way or the other if the above happened. I can however point out that if such a thing happened, then usually a traffic block is announced and all traffic on those lines are stopped. This has been the thing I know for decades. Traveling between Mumbai and Pune multiple times over the years am aware about traffic block. If some repair work was going on and it wasn t able to complete the work within the time-frame then that may well have contributed to the accident. There is also a bit muddying of the waters where it is being said that one of the trains was 4 hours late, which one is conflicting stories.
On top of the whole thing, they have put the case to be investigated by CBI and hinting at sabotage. They also tried to paint a religious structure as mosque, later turned out to be a temple. The RW says done by Muslims as it was Friday not taking into account as shared before that most Railway maintenance works are usually done between Friday Monday. This is a practice followed not just in India but world over.
There has been also move over a decade to remove wooden sleepers and have concrete sleepers. Unlike the wooden ones they do not expand and contract as much and their life is much more longer than the wooden ones. Funds had been marked (although lower than last few years) but not yet spent. As we know in case of any accident, it is when all the holes in cheese line up it happens. Fukushima is a great example of that, no sea wall even though Japan is no stranger to Tsunamis. External power at the same level as the plant. (10 meters above sea-level), no training for cascading failures scenarios which is what happened. The Days mini-series shares some but not all the faults that happened at Fukushima and the Govt. response to it. There is a difference though, the Japanese Prime Minister resigned on moral grounds. Here, nor the PM, nor the Minister would be resigning on moral grounds or otherwise :(. Zero accountability and that was partly a natural disaster, here it s man-made. In fact, both the Minister and the Prime Minister arrived with their entourages, did a PR blitzkrieg showing how concerned they are. Within 50 hours, the lines were cleared. The part-time Railway Minister shared that he knows the root cause and then few hours later has given the case to CBI. All are saying, wait for the inquiry report. To date, none of the accidents even in this Govt. has produced an investigation report. And even if it did, I am sure it will whitewash as it did in case of Adani as I had shared before in the previous blog post. Incidentally, it is reported that Adani paid off some of its debt, but when questioned as to where they got the money, complete silence on that part :(. As can be seen cover-up after cover-up
FWIW, the Coramandel Express is known as the Migrant train so has a huge number of passengers, the other one which was collided with is known as sick train as huge number of cancer patients use it to travel to Chennai and come back
The main takeaway is if you do not have their voice, you won t make policies for them. They won t go away but you will make life hell for them. One thing to keep in mind that most people assume that most people are disabled from birth. This may or may not be true. For e.g. in the above triple Railways accidents, there are bound to be disabled people or newly disabled people who were healthy before the accident. The most common accident is road accidents, some involving pedestrians and vehicles or both, the easiest is Ministry of Road Transport data that says 4,00,000 people sustained injuries in 2021 alone in road mishaps. And this is in a country where even accidents are highly under-reported, for more than one reason. The biggest reason especially in 2 and 4 wheeler is the increased premium they would have to pay if in an accident, so they usually compromise with the other and pay off the Traffic Inspector.
Sadly, I haven t read a new book, although there are a few books I m looking forward to have. People living in India and neighbors please be careful as more heat waves are expected. Till later.
Welcome to the May 2023 report from the Reproducible Builds project
In our reports, we outline the most important things that we have been up to over the past month. As always, if you are interested in contributing to the project, please visit our Contribute page on our website.
Holger Levsen gave a talk at the 2023 edition of the Debian Reunion Hamburg, a semi-informal meetup of Debian-related people in northern Germany. The slides are available online.
In April, Holger Levsen gave a talk at foss-north 2023 titled Reproducible Builds, the first ten years. Last month, however, Holger s talk was covered in a round-up of the conference on the Free Software Foundation Europe (FSFE) blog.
Pronnoy Goswami, Saksham Gupta, Zhiyuan Li, Na Meng and Daphne Yao from Virginia Tech published a paper investigating the Reproducibility of NPM Packages. The abstract includes:
When using open-source NPM packages, most developers download prebuilt packages on npmjs.com instead of building those packages from available source, and implicitly trust the downloaded packages. However, it is unknown whether the blindly trusted prebuilt NPM packages are reproducible (i.e., whether there is always a verifiable path from source code to any published NPM package). [ ] We downloaded versions/releases of 226 most popularly used NPM packages and then built each version with the available source on GitHub. Next, we applied a differencing tool to compare the versions we built against versions downloaded from NPM, and further inspected any reported difference.The paper reports that among the 3,390 versions of the 226 packages, only 2,087 versions are reproducible, and furthermore that multiple factors contribute to the non-reproducibility including flexible versioning information in package.json file and the divergent behaviors between distinct versions of tools used in the build process. The paper concludes with insights for future verifiable build procedures. Unfortunately, a PDF is not available publically yet, but a Digital Object Identifier (DOI) is available on the paper s IEEE page.
Elsewhere in academia, Betul Gokkaya, Leonardo Aniello and Basel Halak of the School of Electronics and Computer Science at the University of Southampton published a new paper containing a broad overview of attacks and comprehensive risk assessment for software supply chain security.
Their paper, titled Software supply chain: review of attacks, risk assessment strategies and security controls, analyses the most common software supply-chain attacks by providing the latest trend of analyzed attack, and identifies the security risks for open-source and third-party software supply chains. Furthermore, their study introduces unique security controls to mitigate analyzed cyber-attacks and risks by linking them with real-life security incidence and attacks . (arXiv.org, PDF)
NixOS is now tracking two new reports at reproducible.nixos.org. Aside from the collection of build-time dependencies of the minimal and Gnome installation ISOs, this page now also contains reports that are restricted to the artifacts that make it into the image. The minimal ISO is currently reproducible except for Python 3.10, which hopefully will be resolved with the coming update to Python version 3.11.
David A. Wheeler started a thread noting that the OSSGadget project s oss-reproducible tool was measuring something related to but not the same as reproducible builds. Initially they had adopted the term semantically reproducible build term for what it measured, which they defined as being if its build results can be either recreated exactly (a bit for bit reproducible build), or if the differences between the release package and a rebuilt package are not expected to produce functional differences in normal cases. This generated a significant number of replies, and several were concerned that people might confuse what they were measuring with reproducible builds . After discussion, the OSSGadget developers decided to switch to the term semantically equivalent for what they measured in order to reduce the risk of confusion.
Vagrant Cascadian (vagrantc) posted an update about GCC, binutils, and Debian s build-essential set with some progress, some hope, and I daresay, some fears .
Lastly, kpcyrd asked a question about building a reproducible Linux kernel package for Arch Linux (answered by Arnout Engelen). In the same, thread David A. Wheeler pointed out that the Linux Kernel documentation has a chapter about Reproducible kernel builds now as well.
In Debian this month, nine reviews of Debian packages were added, 20 were updated and 6 were removed this month, all adding to our knowledge about identified issues. In addition, Vagrant Cascadian added a link to the source code causing various 
ecbuild issues. [ ]
The F-Droid project updated its Inclusion How-To with a new section explaining why it considers reproducible builds to be best practice and hopes developers will support the team s efforts to make as many (new) apps reproducible as it reasonably can.
In diffoscope development this month, version 242 was uploaded to Debian unstable by Chris Lamb who also made the following changes:
binwalk is not available, ensure the user knows they may be missing more info. [ ]0.7.24 and 0.7.25 to Debian unstable which added support for Tox versions 3 and 4 with help from Vagrant Cascadian [ ][ ][ ]
mtools (forwarded upstream).lombok.lcov.lucene8.bnd.clc-intercal.proj.gcc-13.pygopherd.pytorch-audio.vcmi.proj.generateLocaleConfig in Android Gradle Plugin version 8.1.0 generates XML files using non-deterministic ordering, breaking reproducible builds. [ ]
The Reproducible Builds project operates a comprehensive testing framework (available at tests.reproducible-builds.org) in order to check packages and other artifacts for reproducibility. In May, a number of changes were made by Holger Levsen:
arm64 nodes only put required modules in the initrd to save space in the /boot partition. [ ]--fetch, --help, --no-future and --verbose options [ ][ ][ ][ ] as well as adding a suite of new actions, such as apt-upgrade, command, deploy-git, rmstamp, etc. [ ][ ][ ][ ] in addition a significant amount of refactoring [ ][ ][ ][ ].apt has updates to install. [ ]bind9-dnsutils on some Ubuntu 18.04 nodes. [ ][ ]apt upgrades are available. [ ]nocheck, nopgo and nolto when building gcc-* and binutils packages [ ] as well as performed some node maintenance [ ][ ]. In addition, Roland Clobus updated the openQA configuration to specify longer timeouts and access to the developer mode [ ] and updated the URL used for reproducible Debian Live images [ ].
#reproducible-builds on irc.oftc.net.
rb-general@lists.reproducible-builds.org
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | def parse_plain_text_body(text): lines = text.splitlines() for i, line in enumerate(lines): if line == 'Reply to this email directly or view it on GitHub:': return lines[i + 1].split('#')[0] if (line == 'For more details, see:' and lines[i + 1].startswith('https://code.launchpad.net/')): return lines[i + 1] try: (field, value) = line.split(':', 1) except ValueError: continue if field.lower() == 'merge request url': return value.strip() return None |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | pub fn parse_plain_text_body(text: &str) -> Option<String> let lines: Vec<&str> = text.lines().collect(); for (i, line) in lines.iter().enumerate() if line == &"Reply to this email directly or view it on GitHub:" return Some(lines[i + 1].split('#').next().unwrap().to_string()); if line == &"For more details, see:" && lines[i + 1].starts_with("https://code.launchpad.net/") return Some(lines[i + 1].to_string()); if let Some((field, value)) = line.split_once(':') if field.to_lowercase() == "merge request url" return Some(value.trim().to_string()); None |
1 2 3 4 5 6 7 8 9 10 11 12 13 | use pyo3::prelude::*; #[pyfunction] fn parse_plain_text_body(text: &str) -> Option<String> janitor_mail_filter::parse_plain_text_body(text) #[pymodule] pub fn _mail_filter(py: Python, m: &PyModule) -> PyResult<()> m.add_function(wrap_pyfunction!(parse_plain_text_body, m)?)?; Ok(()) |
1 2 3 4 5 6 7 8 9 10 11 12 | [package] name = "mailfilter-py" version = "0.0.0" authors = ["Jelmer Vernoo <jelmer@jelmer.uk>"] edition = "2018" [lib] crate-type = ["cdylib"] [dependencies] janitor-mail-filter = path = "../mailfilter" pyo3 = version = ">=0.14", features = ["extension-module"] |
1 2 3 4 5 6 7 8 9 | #!/usr/bin/python3 from setuptools import setup from setuptools_rust import RustExtension, Binding setup( rust_extensions=[RustExtension( "janitor._mailfilter", "crates/mailfilter-py/Cargo.toml", binding=Binding.PyO3)], ) |
1 | from ._mailfilter import parse_plain_text_body |
I m calling time on DNSSEC. Last week, prompted by a change in my DNS hosting setup, I began removing it from the few personal zones I had signed. Then this Monday the .nz ccTLD experienced a multi-day availability incident triggered by the annual DNSSEC key rotation process. This incident broke several of my unsigned zones, which led me to say very unkind things about DNSSEC on Mastodon and now I feel compelled to more completely explain my thinking:
For almost all domains and use-cases, the costs and risks of deploying DNSSEC outweigh the benefits it provides. Don t bother signing your zones.
The .nz incident, while topical, is not the motivation or the trigger for this conclusion. Had it been a novel incident, it would still have been annoying, but novel incidents are how we learn so I have a small tolerance for them. The problem with DNSSEC is precisely that this incident was not novel, just the latest in a long and growing list.
It s a clear pattern. DNSSEC is complex and risky to deploy. Choosing to sign your zone will almost inevitably mean that you will experience lower availability for your domain over time than if you leave it unsigned. Even if you have a team of DNS experts maintaining your zone and DNS infrastructure, the risk of routine operational tasks triggering a loss of availability (unrelated to any attempted attacks that DNSSEC may thwart) is very high - almost guaranteed to occur. Worse, because of the nature of DNS and DNSSEC these incidents will tend to be prolonged and out of your control to remediate in a timely fashion.
The only benefit you get in return for accepting this almost certain reduction in availability is trust in the integrity of the DNS data a subset of your users (those who validate DNSSEC) receive. Trusted DNS data that is then used to communicate across an untrusted network layer. An untrusted network layer which you are almost certainly protecting with TLS which provides a more comprehensive and trustworthy set of security guarantees than DNSSEC is capable of, and provides those guarantees to all your users regardless of whether they are validating DNSSEC or not.
In summary, in our modern world where TLS is ubiquitous, DNSSEC provides only a thin layer of redundant protection on top of the comprehensive guarantees provided by TLS, but adds significant operational complexity, cost and a high likelihood of lowered availability.
In an ideal world, where the deployment cost of DNSSEC and the risk of DNSSEC-induced outages were both low, it would absolutely be desirable to have that redundancy in our layers of protection. In the real world, given the DNSSEC protocol we have today, the choice to avoid its complexity and rely on TLS alone is not at all painful or risky to make as the operator of an online service. In fact, it s the prudent choice that will result in better overall security outcomes for your users.
Ignore DNSSEC and invest the time and resources you would have spent deploying it improving your TLS key and certificate management.
Ironically, the one use-case where I think a valid counter-argument for this position can be made is TLDs (including ccTLDs such as .nz). Despite its many failings, DNSSEC is an Internet Standard, and as infrastructure providers, TLDs have an obligation to enable its use. Unfortunately this means that everyone has to bear the costs, complexities and availability risks that DNSSEC burdens these operators with. We can t avoid that fact, but we can avoid creating further costs, complexities and risks by choosing not to deploy DNSSEC on the rest of our non-TLD zones.
It s been a very long time I haven t blogged about e-voting, although
some might remember it s been a topic I have long worked with;
particularly, it was the topic of my 2018 Masters
thesis, plus some five articles I
wrote in the 2010-2018 period. After the thesis, I have to admit I got
weary of the subject, and haven t pursued it anymore.
So, I was saddened and dismayed to read that once again, as it has
already happened the electoral authorities would set up a pilot
e-voting program in the local elections this year, that would probably
lead to a wider deployment next year, in the Federal elections.
This year ( this week!), two States will have elections for their
Governors and local Legislative branches: Coahuila (North, bordering
with Texas) and Mexico (Center, surrounding Mexico City). They are
very different states, demographically and in their development
level.
Pilot programs with e-voting booths have been seen in four states
TTBOMK in the last ~15 years: Jalisco (West), Mexico City, State of
Mexico and Coahuila. In Coahuila, several universities have teamed up
with the Electoral Institute to develop their e-voting booth; a good
thing that I can say about how this has been done in my country is
that, at least, the Electoral Institute is providing their own
implementations, instead of sourcing with e-booth vendors (which have
their long, tragic story mostly in the USA, but also in other
places). Not only that: They are subjecting the machines to audit
processes. Not open audit processes, as demanded by academics in the
field, but nevertheless, external, rigorous audit processes.
But still, what me and other colleagues with Computer Security
background oppose to is not a specific e-voting implementation, but
the adoption of e-voting in general. If for nothing else, because of
the extra complexity it brings, because of the many more checks that
have to be put in place, and Because as programmers, we are aware
of the ease with which bugs can creep in any given
implementation both honest bugs (mistakes) and, much worse, bugs
that are secretly requested and paid for.
Anyway, leave this bit aside for a while. I m not implying there
was any ill intent in the design or implementation of these e-voting
booths.
Two days ago, the Electoral Institute announced there was an important
bug found in the Coahuila implementation. The bug consists, as far as
I can understand from the information reported in newspapers, in:
During the weekend of 19-23 May 2023 I attended the Wikimedia hackathon 2023 in Athens,
Greece. The event physically reunited folks interested in the more technological aspects of the Wikimedia movement in person for the
first time since 2019. The scope of the hacking projects include (but was not limited to)
tools, wikipedia bots, gadgets, server and network infrastructure, data and other technical systems.
My role in the event was two-fold: on one hand I was in the event because of my role as SRE in the Wikimedia Cloud Services team, where we provided
very valuable services to the community, and I was expected to support the technical contributors of the movement that were around. Additionally, and
because of that same role, I did some hacking myself too, which was specially augmented given I generally collaborate on a daily basis with some
community members that were present in the hacking room.
The hackathon had some conference-style track and I ran a session with my coworker Bryan, called
Past, Present and Future of Wikimedia Cloud Services (Toolforge and friends)
(slides) which was very satisfying to deliver given the friendly space
that it was. I attended a bunch of other sessions, and all of them were interesting and well presented. The number of ML themes that were present in
the program schedule was exciting. I definitely learned a lot from attending those sessions, from how LLMs work, some
fascinating applications for them in the wikimedia space, to what were some industry trends for training and hosting ML models.
Despite the sessions, the main purpose of the hackathon was, well, hacking. While I was in the hacking space for more than 12 hours each day, my
ability to get things done was greatly reduced by the constant conversations, help requests, and other social interactions with the folks. Don t get
me wrong, I embraced that reality with joy, because the social bonding aspect of it is perhaps the main reason why we gathered in person instead of
virtually.
That being said, this is a rough list of what I did:
It wasn t the first Wikimedia Hackathon for me, and I felt the same as in previous iterations: it was a welcoming space, and I was surrounded by
friends and nice human beings. I ended the event with a profound feeling of being privileged, because I was part of the Wikimedia movement, and
because I was invited to participate in it.
| Series: | Mossa and Pleiti #1 |
| Publisher: | Tordotcom |
| Copyright: | 2023 |
| ISBN: | 1-250-86051-2 |
| Format: | Kindle |
| Pages: | 169 |
Apart from it, the show also shows prejudice about caste and background. I wouldn t go much into it as it s worth seeing and experiencing.
Content Security Policy: Ignoring 'unsafe-inline' within script-src or style-src: nonce-source or hash-source specifiedContent Security Policy: The page s settings blocked the loading of a resource at data:text/css,%0A%20%20%20%20%20%20%20%2 ( style-src ). data:44:30Content Security Policy: Ignoring 'unsafe-inline' within script-src or style-src: nonce-source or hash-source specifiedTypeError: AudioContext is not a constructor 138875 https://discord.com/assets/cbf3a75da6e6b6a4202e.js:262 l https://discord.com/assets/f5f0b113e28d4d12ba16.js:1ed46a18578285e5c048b.js:241:118
What is being done is dom.webaudio.enabled being disabled in Firefox.
Then on a hunch, searched on reddit and saw the following. Be careful while visiting the link as it s labelled NSFW although to my mind there wasn t anything remotely NSFW about it. They do mention using another tool AudioContext Fingerprint Defender which supposedly fakes or spoofs an id. As this add-on isn t tracked by Firefox privacy team it s hard for me to say anything positive or negative.
So, in the end I stopped using discord as the alternative was being tracked by them
Last but not the least, saw this about a week back. Sooner or later this had to happen as Elon tries to make money off Twitter.
Thank you to Holger for organising this event yet again!
It wouldn t be inaccurate to say that I ve had a lot on my plate in the last few years, and that I have a *huge* backlog of little tasks to finish. Just last week, I finally got to all my keysigning from DebConf22. This week, I m at MiniDebConf Germany in Hamburg. It s the second time I m here! And it s great already. Last year I drafted a blog entry, but never got around to publishing it. So, in order to mentally tick off yet another thing, here follows a somewhat imperfect (I had to delete a lot of short-hand because I didn t know what it means anymore), but at least published post about my activities from a year ago.
This week (well, last year) I attended my first ever in-person MiniDebConf and MiniDebCamp in Hamburg, Germany. The last time I was in Germany was 7 years ago for DebConf15 (or at time of publishing, actually, last year for this same event).
My focus for the week was to work on Debian live related stuff.
In preparation for the week I tried to fix/close as many Calamares bugs as I could, so before the event I closed:
I've been watching the neovim community for a while and what seems like a
cambrian explosion of plugins emerging. A few weeks back I decided to spend
most of a "day of learning" on investigating some of the plugins and
technologies that I'd read about: Language Server
Protocol,
TreeSitter,
neorg (a grandiose organiser plugin),
etc.
It didn't go so well. I spent most of my time fighting version
incompatibilities or tracing through scant documentation or code to figure out
what plugin was incompatible with which other.
There's definitely a line where crossing it is spending too much time playing
with your tools instead of creating. On the other hand, there's definitely
value in honing your tools and learning about new technologies. Everyone's line
is probably in a different place. I've come to the conclusion that I don't have
the time or inclination (or both) to approach exploring the neovim universe in
this way. There exist a number of plugin "distributions" (such as LunarVim): collections of pre-
configured and integrated plugins that you can try to use out-of-the-box. Next
time I think I'll pick one up and give that a try &emdash independently
from my existing configuration &emdash and see which ideas from it I might like to
adopt.
shared vimrcs
Some folks upload their vim or neovim configurations in their entirety for
others to see. I noticed Jess Frazelle had published
hers so I took a look. I suppose one could
evaluate a bunch of plugins and configuration in isolation using a shared vimrc
like this, in the same was as a distribution.
bufferline
Amongst the plugins she uses was bufferline, a plugin to re-work neovim's
tab bar to behave like tab bars from more conventional editors1. I don't make
use of neovim's tabs at all2, so I would lose nothing having the (presently hidden)
tab bar reworked, so I thought I'd give it a go.
I had to disable an existing plugin lightline, which I've had enabled for years
but I wasn't sure I was getting much value from. Apparently it also messes with the
tab bar! Disabling it, at least for now, at least means I'll find out if I miss it.
I am already using
vim-buffergator as a means
of seeing and managing open buffers: a hotkey opens a sidebar with a list of
open buffers, to switch between or close. Bufferline gives me a more immediate,
always-present view of open buffers, which is faintly useful: but not much.
Perhaps I'd like it more if I was coming from an editor that had made it more
of an expected feature. The two things I noticed about it that aren't
especially useful for me: when browsing around vimwiki pages, I quickly
open a lot of buffers. The horizontal line fills up very quickly. Even when I
don't, I habitually have quite a lot of buffers open, and the horizontal line
is quickly overwhelmed.
I have found myself closing open buffers with the mouse, which I didn't do
before.
vert
Since I have brought up a neovim UI feature (tabs) I thought I'd briefly mention
my new favourite neovim built-in command: vert.
Quite a few plugins and commands open up a new window (e.g. git-fugitive,
Man, etc.) and they typically do so in a horizontal split. I'm increasingly
preferring vertical splits. Prefixing any3 such command with vert forces
the split to be vertical instead.
Next.