Note on all the #xz drama, there are some technical solutions for such #supplychainattack that can make such an attack way harder, at least to hide the code in tarballs etc.
slsa.dev/ e.g. is a solution. Combined with reproducible builds, it ensures that a software artifact is built exactly from the source given in a source repository, with the possibility to prove that and no way for any maintainer to tamper with (in the highest level).
SLSA is a security framework. It is a check-list of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure in your projects, businesses or enterprises.
Of course practically, people (especially software consumers) needed to verify it, to be worth the work.
Obviously, it's no magic bullet. It just raises the burden for an attacker. Obviously, the source code repo could be made to contain bad code, but you cannot anymore tamper at built-time.
The problem Any software can introduce vulnerabilities into a supply chain. As a system gets more complex, it’s critical to already have checks and best practices in place to guarantee artifact int...
The way this works, is, essentially, quite easy: the whole build process is documented in the same repository, builds are automated via CI/CD and all that is, to reach best support, done in an environment that prevents tampering and (crucially) is *out of your control*.
Now, you say, you have to trust GitHub? Sure, you do, to achieve this. But threat models: What is more likely compromised: a maintainer/account in your project, or the whole GitHub build infra?
Personally, I was also not quite convinced, given you loose "control" over your build and GitHub could theoretically now inject #malware.
However, as the project itself states, this is not a big deal, if you combine it with the older security feature aka #reproduciblebuilds.
To explain, we have #SLSA signatures that verify the build was done automatically by #GitHub as instructed, *and* we have traditional #gpg signatures with private keys only known to maintainer(s) that verify a maintainer actually triggered the built and locally reproduced it… Given they both validate, you automatically achieve reproducible builds _and_ #SLSA validity.
One caveat: This was only easy, because our build process is essentially one command (git archive).
A minimalist, open source online pastebin where the server has zero knowledge of pasted data. Data is encrypted/decrypted in the browser using 256 bits AES. - PrivateBin/PrivateBin
Wow, je mehr ich über die ganze #xz Saga lese, desto beeindruckter bin ich, was für ein unglaublicher Zufall es war, dass das so schnell gefunden wurde 😳
bugs.debian.org/cgi-bin/bugrep… gibt einen guten Eindruck, wie vor 5-6 Tagen angefangen wurde, Druck aufzubauen, die kompromittierte Version in Debian hochzuladen. Und wie viel Energie da rein gesteckt wurde.
I couldn't immediately tell, but is sigstore (sigstore.dev/) a part of that approach, or is it a different project doing something similar (but only a part of the what'd be required)?
Gerade @Malte 's exzellente Einführung in SSRF (server side request forgery) genossen am #Winterkongress und fleissig Notizen gemacht. Habe da noch ein paar Punkte am PrivateBin directory nachzubessern. Gopher-URLs via (lib)curl zu nutzen um ganz andere Protokolle zu sprechen (das gezeigte Beispiel war SMTP) ist echt kreativ, aber wenigstens recht einfach zu unterbinden.
A classic bug for a leap day: At work, colleagues discovered and fixed a bug in a lesser used tool that only occurs on February 29th. It did trip up the tests, so no one got to merge until it got identified and resolved.
The source file in question hadn't been touched in over 4 years. Last leap year, the 29th was on a Saturday, so likely no one noticed.
What was annoying is that the logic had been clearly written with the intent of handling leap years. A leap year check condition was present, validated only on a February > 28th, but had to get inverted.
You may wonder why we wouldn't have used the languages' standard library date functions to validate the date - unfortunately the language in question doesn't have such a sophisticated standard library (language omitted to protect the innocent).
Niklaus Wirth, the inventor of the Pascal programming language, author of "Algorithms + Data Structures = Programs", and more, passed away on January 1.
Wirth's law, named after him, is an adage which states that software gets slower more rapidly than hardware gets faster.
Through these interviews, we aim to make security easier and more efficient for OSS projects. Anyone over the age of 18 who regularly contributes to at least one OSS project, and has contributed to an OSS project for at least one year, is eligible --- no security background or experience required.
Interview participants will receive a $40.00 Amazon or Tango gift card for completing one 60-75 minute interview via Zoom. We will pr
Through these interviews, we aim to make security easier and more efficient for OSS projects. Anyone over the age of 18 who regularly contributes to at least one OSS project, and has contributed to an OSS project for at least one year, is eligible --- no security background or experience required.
Interview participants will receive a $40.00 Amazon or Tango gift card for completing one 60-75 minute interview via Zoom. We will protect the privacy and confidentiality of any information shared during the interviews to the utmost of our abilities.
If you might be interested, please fill out this survey to answer some initial questions. Contact Carson Powers or Harjot Kaur with any questions about the study, or click here to learn more!
I had the opportunity to participate in an interview last week with Harjut and Carson and wish them success in furthering our collective insights into how we can improve security of our FOSS software projects. It is, in my own expirience, an often thank-less task, but important to do. So any way of making it more popular will help us all in the long run.
Also, as an aside, I look forward meeting some of you at the #37c3 very soon. 😷
I got to follow rocket's journey to async and stable #rust with the PrivateBin directory service. Coming from Python flask apps, it is really easy to pick up and get going with your webservice, offering static & templated content, easy to create web forms and JSON APIs.
Thanks to rust's strict type system I could focus on the logic and didn't have to waste time double checking and casting data received by clients. If my API accepts an integer in a certain parameter, Rocket will ensure I only receive valid requests in my logic.
I’m excited to announce v1.0 of hyper, a protective and efficient HTTP library written in the Rust programming language. hyper provides asynchronous HTTP/1 a...
In order not to spam everyone, here just one post linking to the photos from my holiday in Peru. Feel free to comment or ask if you're interested in more details. Sharing this here as I could not do so via the tour groups whatsapp.
In order not to spam everyone, here just one post linking to the photos from my holiday in Peru. Feel free to comment or ask if you're interested in more details. Sharing this here as I could not do so via the tour groups whatsapp.
As you can imagine, I greatly enjoyed this trip. There is so much more history to learn about and archeological sites to see than I imagined. Food and people are great, and I only regret that my Spanish is so basic that I could not chat more with the locals. Yes, I did try Cuy (guinea pig) & Alpaka, and no, they don't taste like chicken at all.
I like CSS-animations, clocks and dials for making metrics easier to digest (we are quicker at detecting angular changes than reading and parsing digits). So I'm in awe with this creative use of a watch-dial to visualize a 32-bit hexadecimal number:
#PrivateBinv1.6.0 released - adding translations for Japanese & Arabic, configuration option to disable email button and increases the minimal required PHP version to 7.3.
We are still looking for additional long term maintainers. What can we offer you in return for your help?
We can offer you our mentorship, if this is your first time participating as a maintainer of an open source software project. We can guide you through submitting your first pull requests and work with you to ensure your change fulfills the communities quality standards, gets merged and makes it into a release.
Your work gets publicly credited. This can help you build up a resume, showing off your growing skill set, in programming as well as your soft skills.
PrivateBin is a smaller project. If you'd like to learn how to participate and contribute in an open source git project, this should be less overwhelming then larger projects.
We are still looking for additional long term maintainers. What can we offer you in return for your help?
We can offer you our mentorship, if this is your first time participating as a maintainer of an open source software project. We can guide you through submitting your first pull requests and work with you to ensure your change fulfills the communities quality standards, gets merged and makes it into a release.
Your work gets publicly credited. This can help you build up a resume, showing off your growing skill set, in programming as well as your soft skills.
PrivateBin is a smaller project. If you'd like to learn how to participate and contribute in an open source git project, this should be less overwhelming then larger projects.
We do have a decent unit test code coverage, so it is an environment forgiving of mistakes. You may still introduce logical flaws or issues in new features, not yet covered in the tests, but you can rely on the tests preventing any regressions in other areas.
You don't have to be proficient in multiple programming languages, there are a lot of things to improve within either the JavaScript or PHP areas that don't need you to understand the other side, beyond their shared API.
It can be an opportunity to learn about continuos integration tools to automate tasks like tests, security scans, etc.
If you are interested in helping with any of these points, we have prepared a development guide including design goals, code structure and tools to get you started. For any questions, you can chat with the maintainers in the discussion area or reach us via email or here in the Fediverse.
At work we use more and more YAML documents (with all it's benefits and issues) so I've long started using a handy python alias to convert them into JSON to query them using jq:
alias yaml2json='python3 -c '\''import sys, yaml, json; y=yaml.safe_load(sys.stdin.read()); print(json.dumps(y))'\'''
Because we also started using it in the test harness to validate YAML documents, we made it available to that environment as well. Test creates some YAML report, which is piped into yaml2json, which is piped into jq --exit-status '[...tests here...]'.
Fast forward a few months, more tests got added, and eventually I notice that one of these, on a 30k line document, spends about 15 seconds just converting it. Hm.
Now, it's not like there are not already tons of C, C++, Go, Rust, etc. versions of that tool around, I'm aware of many of those, unfortunately none are p
... mehr anzeigen
At work we use more and more YAML documents (with all it's benefits and issues) so I've long started using a handy python alias to convert them into JSON to query them using jq:
alias yaml2json='python3 -c '\''import sys, yaml, json; y=yaml.safe_load(sys.stdin.read()); print(json.dumps(y))'\'''
Because we also started using it in the test harness to validate YAML documents, we made it available to that environment as well. Test creates some YAML report, which is piped into yaml2json, which is piped into jq --exit-status '[...tests here...]'.
Fast forward a few months, more tests got added, and eventually I notice that one of these, on a 30k line document, spends about 15 seconds just converting it. Hm.
Now, it's not like there are not already tons of C, C++, Go, Rust, etc. versions of that tool around, I'm aware of many of those, unfortunately none are prepackaged for the distro used around here. Still, it nags me. I know that in Rust we have all these convenient Serde libraries. Would be trivial to write it using these. People have done so. Hm. And we could make a little wrapper around jq, like yq (python), which makes it easier to use. And we could also support other formats, like XML or CSV, like yq (Go) - the latter also replicates jq itself, that seems a step too far and risks running into incompatibilities, jq itself does the job alright.
So, eventually I did put these puzzle pieces together and we have yet-another-format-to-JSON-converter: github.com/simonrupf/convert2j…
Unique selling points? Well I've experimented a bit with github actions and it is indeed not to difficult to automate the release and publication of statically linked RPMs (for use on different RPM-based distros) and dynamically linked binaries for Ubuntu, MacOS (universal binaries for x86_64 & aarch64) and even Windows (untested - I have no access to that OS, nor do I want to). I'll try to keep it light weight and have some automation set up to keep it updated when dependencies change.
And yes, that 30k YAML file now parses in 0.2s instead of 13s. OCD satisfied.
For over 15 years, most PHP setups I maintained were based on a stack of nginx webserver and PHP-fpm. So, unsurprisingly, the container images I maintain for PrivateBin also use this setup. A while ago, I stumbled on the nginx unit project, which describes itself as:
Unit is a lightweight and versatile application runtime [and] was created by nginx team members from scratch [...].
There is a package for it and it's PHP 8.1 module in the stable Alpine Linux repositories (and soon also for PHP 8.2, when Alpine 3.18 releases). It's installed size is about half of the regular nginx package and because it is a single service one no longer needs a service manager in the container, to keep the two services alive.
Tw
... mehr anzeigen
For over 15 years, most PHP setups I maintained were based on a stack of nginx webserver and PHP-fpm. So, unsurprisingly, the container images I maintain for PrivateBin also use this setup. A while ago, I stumbled on the nginx unit project, which describes itself as:
Unit is a lightweight and versatile application runtime [and] was created by nginx team members from scratch [...].
There is a package for it and it's PHP 8.1 module in the stable Alpine Linux repositories (and soon also for PHP 8.2, when Alpine 3.18 releases). It's installed size is about half of the regular nginx package and because it is a single service one no longer needs a service manager in the container, to keep the two services alive.
Two weeks ago I started toying with it and last weekend I finalized the work. It lets you configure all deviations from the default php.ini via it's own service configuration file, so I now got all the configurations in a single file. It took a bit of work to replicate most former settings over to it. Nginx unit doesn't (yet) allow to set custom HTTP headers, which we use to improve security on the static resources and to prevent cloudflare users getting errors (cloudflare will by default try to optimize all Javascript files for performance, but that breaks the SRI-hashes of our application, so the app doesn't load). It also doesn't allow configuring inline gzip compression of text-based resources.
For now I've documented these limitations in the forked repository and have started testing it first on a personal PrivateBin instance and since that worked well, now switched the main demo instance over to it. The HTTP port and all volumes still attach at the same places, the same UID & GID are used and both logs and included maintenance scripts work the same as before, so it is as close to a drop-in replacement as possible.
So far I've observed slightly higher RAM usage (223 MiB vs 190 MiB used, for a VM that also runs the nginx webserver, for TLS termination, serves the static project webpage and runs the PrivateBin directory application server, all in docker containers) and no observable difference in load (still idles at less than 1%). The images are all about 1 MiB less in compressed size (as displayed on the docker hub in the tags).
I'll probably start migrating myotherPHP-fpm containers over to unit, but I'll probably wait for that Alpine 3.18 release, so I can switch to PHP 8.2 at the same time. It's a much simpler stack to maintain.
Schade das zu erfahren und vielen Dank an Herrn Dornier für die jahrzehnte-lange gute Betreuung und die ausgezeichneten Produkte!
Habe beruflich und privat seit Ende der 2000er Jahre immer wieder auf PC Engines für m0n0wall- und später OPNsense-basierte Router gesetzt. Diese Nachricht wurde über eine apu4d4 ins Internet geschickt und von einem Server hinter einer apu2e4 gehostet.
Last week, Microsoft announced the new AI-powered Bing: a search interface that incorporates a language model powered chatbot that can run searches for you and summarize the results, plus do …
Während zwei Tagen werden Themen rund um Informationstechnologie, Digitalisierung und deren Auswirkungen auf unsere Gesellschaft in verschiedenen Vorträgen und Workshops behandelt.
@aris the bindings are all maintained elsewhere so the burden is widely distributed. I think our stable API and ABI and not breaking behavior has helped all as they remain functional and over time can mature.
what’s a good use-case for PyCurl, etc? I use curl on the command like daily, but not sure what I would do with it in a program. I’m sure that I’m missing something.
While python 3 now has decent native support for HTTP(S) with it's urllib module (which does cover 99+% of my use cases), PyCurl supports "FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS, FILE, IMAP, SMTP, POP3 and RTSP. libcurl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate, Kerberos4), file transfer resume, http proxy tunneling and more!" -- pycurl.io/
So it can solves those edge cases. It may also be useful if you hit performance or memory usage issues in your python based search spider or similar massively parallel connection applications.
This minor release adds support for Simple Storage Service (S3), a storage migration script, adds four new languages to the translations and includes updated libraries.
My team at LzLabs GmbH in Wallisellen, Switzerland, is looking for a 4th DevOps Engineer. You'd be working primarily with a CloudBees (Jenkins) cluster of around 90 blades for build & testing, for several software stacks that targets RHEL, but hopefully soon™ also other platforms. And of course there are also a lot of build and deployment related projects to be spice things up on the side, like maintaining and developing a test statistics database, code coverage reporting, change log and other automation projects, all in a mostly ansible-ized environment. The companies main language is English, living in or moving to the vicinity of Zürich would certainly be advantageous.
As one of our DevOps engineers you will join a team who lead the way for our CI/CD environment. The ideal engineer will bring experience, best practices, and a collaborative attitude to help drive Linux based CI/CD initiatives.
Yeah, das Friendica Update war wieder einmal ein voller Erfolg! Ich freue mich immer darauf nach dem Update die Netzwerkstatistiken zu durchstöbern und zu sehen wie das Fediverse wächst und gedeiht. Aktuell sehe ich da bei mir:
Momentan kennt dieser Knoten 2065 Knoten mit insgesamt 1238363700 registrierten Nutzern, die die folgenden Plattformen verwenden: - Friendica (234/14306) - BirdsiteLIVE (3/9295) - Diaspora (104/745029) - [...] - Lemmy (4/15876) - Mastodon (1195/2801105) - Misskey (33/1234575069) [...]
Hm, die Misskey stats bedürfen wohl noch etwas der Interpretation... 🤔
Oh, wow: Nachdem ich von den beiden Druckwellen des Vulkanausbruches in der Nähe von Tonga hörte, habe ich in den Messungen von meiner kleinen Wetterstation nachgeguckt und die sind dort klar zu erkennen!
Als ich 1997 meine erste Reise in die USA machte, hatte ich einen Psion Siena dabei und darauf Tagebuch geführt. Leider konnte ich mir damals das Datenkabel nicht leisten und es irgendwann verpasst die leeren Batterien zu tauschen und die Dokumente gingen so verloren.
Vor einigen Wochen habe ich mir aus Neugier dessen grossen Bruder angeschafft, den Psion Series 3a. Und diesmal auch ein serielles Kabel dazu, damit ich Programme hoch- und Daten davon runter laden kann. Hab mal ein paar Notizen dazu gemacht:
The application in question is my first foray into the rust language and a very simple, CRUD-style web application. It consists of: - a page with list of entries in a database, sorted by fixed criteria, for now - a single JSON API endpoint to retrieve that same list, with optional filters - a form to add an entry to the list - a nearly static about page - two tasks started via cron jobs, one running every few minutes and the other once a day
The rocket framework appealed to me because it offered a similar semantic to flask for python. It comes with several options for templating and state (aka database) integrations. I had picked tera templates, as they are near identical to jinja2 templates that are used all over python application (i.e. in pelican, ansible, flask, ...) and diesel for accessing an sql
... mehr anzeigen
The application in question is my first foray into the rust language and a very simple, CRUD-style web application. It consists of: - a page with list of entries in a database, sorted by fixed criteria, for now - a single JSON API endpoint to retrieve that same list, with optional filters - a form to add an entry to the list - a nearly static about page - two tasks started via cron jobs, one running every few minutes and the other once a day
The rocket framework appealed to me because it offered a similar semantic to flask for python. It comes with several options for templating and state (aka database) integrations. I had picked tera templates, as they are near identical to jinja2 templates that are used all over python application (i.e. in pelican, ansible, flask, ...) and diesel for accessing an sqlite database. The rocket framework was already at version 0.4 when I started out with the project in 2020. It used a synchronous version of hyper, a low-level HTTP library to provide a multi-threaded HTTP server. It lets you compile the entire application into a single statically linked binary, excellent to run in a small "FROM scratch" container image.
In June 2021, the rocket 0.5 release candidate got published, and over the quieter days end of 2021 / beginning of 2022, I dug into upgrading the app. Let's start with the best bits about this process and the end result: - I didn't need to do any changes to the templates, the CSS, the database structures or queries. The rocket routing mechanism worked the same way as before. - rocket 0.5 is now compiling on a stable rust compiler, where 0.4 required the use of the nightly compiler (meaning it used some unstable language features). It got rewritten to use asynchronous functions, which allows it to use the latest hyper library which leverages that mechanism on top of a multi-threaded runtime provided by tokio, an implementation of the green threads concept in Rust.
For this particular application, the average latency was reduced from 67ms to 60ms (as monitored by a zabbix proxy running an a host attached to the same subnet) and the daily cronjob duration got reduced from 52s, using multi-threading, to 22s, using async and the tokio runtime (the earliest, fully linear, implementation of that task took 20 minutes).
While I am happy with these clear improvements, they did come at some cost: - In the end I spent about 7 workdays on this upgrade, spread over 2 weekends and several evenings - git tells me that this consisted of 6188 additions and 4231 deletions, including all the license changes. - The switch to async/await in both rocket and hyper required that many formerly synchronous functions had to be made async as well, as they now needed to call async functions themselves. Rust would offer you the block_on construct to call async functions from sync ones, but that conflicts with the tokio runtime and causes it to fail. The same is true for spawning threads, which I had done extensively in parts of the code that run multiple HTTP(S) requests in parallel. Using tokio to let the async calls be handled automatically did pay off and is indeed faster then my manual optimizations, but the rewrite into async required pretty big code changes. - The newer hyper version lost some features I had been relying on, like shorter connection timeouts (I replaced these with a timeout wrapper on the returned future and an ugly workaround to return an error) and IDN domain names (I now use the URL parser from servo, developed for Firefox). - The unit tests also needed to be made async aware and tokio provides a dedicated macro for wrapping tests. Unfortunately I had to give up on one unit test that I just couldn't get to work under a tokio runtime, while the error couldn't be reproduced on the running service, either manually or scripted. It seems the tokio runtime acts differently when in a unit test, where it keeps telling me it can't launch a runtime from within a runtime. The stack traces seem to go remain outside any of my code, so doesn't even seem to enter any part of the unit test itself. - Due to all these new and upgraded libraries the statically linked binary ended up growing (after stripping and upx-ing) from 2.16 MiB to 2.83 MiB. Sure, compared to a full PHP- or Python-stack it is still at least an order of magnitude smaller, but it's also an increase of 1/3.
I would still recommend rocket to anyone familiar with flask. Creating dynamic web pages or APIs is very straight forward to do. The issues I encountered with the switch to async would not apply to new projects anyway. For existing rocket v0.4 applications, the upgrade is worthwhile if you can use the extra performance or aren't doing weird multi-threaded things in the background, like me. None of the core rocket features broke, only the database abstraction required modest changes. My struggle was mostly with the use of hyper as a client.
For the database side, diesel isn't quite as elegant as ORMs in other languages. It makes it simple to retrieve (lists of) elements from a table and do simple joins. For more complex things you can fall back to writing manual SQL queries and mapping the result onto your structs for convenience (you can mark properties that aren't tied to specific table columns, so you can populate them from calculations on joined tables or such). The database migration mechanism also requires the use of plain SQL.
As a brief follow up, I did eventually manage to fix that last unit test. It was a pretty large end-to-end affair, where I used both rocket's Client, to send form data, and also triggered the cron jobs that use their own rocket instances, but only to extract the database connection. This seems to have been the cause of the tokio within tokio runtime issue. I simply split this into two tests, one that used the form and the other to test all the cron job functions.
The binary acts as a multi-call one, when started with the regular rocket environment parameters it will launch the web service. But if the CRON environment variable is detected it will only execute the requested cron mode and exit. This is not a normal use case for a rocket application, so I can only really blame myself for this quirk.
One thing I did also find out is that my test code did have side effects, because most tests use a shared database (sqlite), so I had to switch to running all tests single-threaded (which is slower, takes up to 10s) as otherwise I got random failures when some tests deleted oth
... mehr anzeigen
As a brief follow up, I did eventually manage to fix that last unit test. It was a pretty large end-to-end affair, where I used both rocket's Client, to send form data, and also triggered the cron jobs that use their own rocket instances, but only to extract the database connection. This seems to have been the cause of the tokio within tokio runtime issue. I simply split this into two tests, one that used the form and the other to test all the cron job functions.
The binary acts as a multi-call one, when started with the regular rocket environment parameters it will launch the web service. But if the CRON environment variable is detected it will only execute the requested cron mode and exit. This is not a normal use case for a rocket application, so I can only really blame myself for this quirk.
One thing I did also find out is that my test code did have side effects, because most tests use a shared database (sqlite), so I had to switch to running all tests single-threaded (which is slower, takes up to 10s) as otherwise I got random failures when some tests deleted others data or couldn't add new instances when these were already present. This could obviously be fixed by either providing each test with a mock database or just be more careful designing the tests such that their order doesn't matter (i.e. using unique keys to add to the database for each test.
Mit Clive Sinclair ist einer der IT-Pioniere Europas gestorben. Der Brite war viel mehr als nur der Unternehmer, der mit den preiswerten ZX-Heimrechnern die Mikrocomputer-Revolution vorantrieb. Ein Nachruf von Martin Wolf (Wissenschaft, Technologie)
My employer is looking for a Junior and a Senior Web Developer in Wallisellen, Switzerland. Please feel free to share and/or message me privately or publicly, if you want to know more about the company.
Die Medien in diesem Beitrag werden Besuchern nicht angezeigt. Um sie anzuzeigen, melden Sie sich bitte an.
Not entirely serious question: Why does the Gnome Terminal icon represent an IBM PC DOS prompt instead of UNIX shell prompt? Is that what folks think of first, when they think of a command prompt?
The book's title and subject is the one liner that produces a maze on the Commodore 64 BASIC V2. In one of the chapters the books authors consider ports to other 8 bit systems, as well as modern scripting languages, using unicode characters. Here is their port to perl:
Yes, shell parsing is non-obvious - it does help enormously to understand that the shell takes what you type on the command line after you hit enter, parses it, replacing variables, expanding globs (wildcards) and other language constructs in the process and only then issues a system call, passing the resulting argv structure to the kernel for execution.
Erst nach einigem Verdauen kann ich nun genau benennen, was mich eigentlich so besonders an Googles neuem FLoC Tracking stört: Es kehrt das Prinzip um, dass man Herr seiner eigenen Internet Domäne(n) ist.
Ich gebe Geld dafür aus, meine eigenen Server zu housen und für die Registrierung meiner eigenen Internet-Domänen. Bisher konnte ich so frei entscheiden, ob ich da Werbung und Tracking darauf einbauen will oder nicht. Ich hatte mich stets dagegen entschieden. Das war einfach, ich musste somit auch nichts in meinen Content einbauen und pflegen. Und die Seiten sind erst noch schlanker und ich kann sicher sein, dass diese auch genau so ausschauen wie ich es will und nicht von Werbung verunstaltet werden.
FLoC kehrt dieses Prinzip um: Besucher meiner Webseiten werden ge-trackt, wenn Sie Chrome benutzen und zur Gruppe gehören bei denen das "Experiment" zufällig aktiviert wurde, und ich muss nun aktiv einen neuen HTTP header in alle meine Webseiten einbauen, damit die Besucher nicht getrackt werden! Und hoffen, dass Chrome sich auch
... mehr anzeigen
Erst nach einigem Verdauen kann ich nun genau benennen, was mich eigentlich so besonders an Googles neuem FLoC Tracking stört: Es kehrt das Prinzip um, dass man Herr seiner eigenen Internet Domäne(n) ist.
Ich gebe Geld dafür aus, meine eigenen Server zu housen und für die Registrierung meiner eigenen Internet-Domänen. Bisher konnte ich so frei entscheiden, ob ich da Werbung und Tracking darauf einbauen will oder nicht. Ich hatte mich stets dagegen entschieden. Das war einfach, ich musste somit auch nichts in meinen Content einbauen und pflegen. Und die Seiten sind erst noch schlanker und ich kann sicher sein, dass diese auch genau so ausschauen wie ich es will und nicht von Werbung verunstaltet werden.
FLoC kehrt dieses Prinzip um: Besucher meiner Webseiten werden ge-trackt, wenn Sie Chrome benutzen und zur Gruppe gehören bei denen das "Experiment" zufällig aktiviert wurde, und ich muss nun aktiv einen neuen HTTP header in alle meine Webseiten einbauen, damit die Besucher nicht getrackt werden! Und hoffen, dass Chrome sich auch daran hält.
Nein danke, ich will die Besucher meiner Webseiten keiner unnötigen Überwachung aussetzen. Schade, dass ich nun Aufwand treiben muss um dies zu erreichen, anstatt einfach keine Tracker oder Werbung einzubauen.
rugk
Als Antwort auf rugk • • •Furthermore produced software artifacts proofs are written into a database similar to #certificateTransparency.
We have recently implemented this in #PrivateBin and it works great: github.com/PrivateBin/PrivateB…
Of course practically, people (especially software consumers) needed to verify it, to be worth the work.
Obviously, it's no magic bullet. It just raises the burden for an attacker. Obviously, the source code repo could be made to contain bad code, but you cannot anymore tamper at built-time.
Getting SLSA ("Supply-chain Levels for Software Artifacts") compliance · Issue #1169 · PrivateBin/PrivateBin
GitHubrugk
Als Antwort auf rugk • • •The way this works, is, essentially, quite easy: the whole build process is documented in the same repository, builds are automated via CI/CD and all that is, to reach best support, done in an environment that prevents tampering and (crucially) is *out of your control*.
Then you get #SLSA v3: slsa.dev/get-started#slsa-3 (quite easy with GitHub Actions)
Get started
SLSArugk
Als Antwort auf rugk • • •Now, you say, you have to trust GitHub? Sure, you do, to achieve this. But threat models: What is more likely compromised: a maintainer/account in your project, or the whole GitHub build infra?
Personally, I was also not quite convinced, given you loose "control" over your build and GitHub could theoretically now inject #malware.
However, as the project itself states, this is not a big deal, if you combine it with the older security feature aka #reproduciblebuilds.
slsa.dev/spec/v1.0/faq#q-what-…
Frequently asked questions
SLSArugk
Als Antwort auf rugk • • •To explain, we have #SLSA signatures that verify the build was done automatically by #GitHub as instructed, *and* we have traditional #gpg signatures with private keys only known to maintainer(s) that verify a maintainer actually triggered the built and locally reproduced it…
Given they both validate, you automatically achieve reproducible builds _and_ #SLSA validity.
One caveat: This was only easy, because our build process is essentially one command (git archive).
github.com/PrivateBin/PrivateB…
PrivateBin/doc/Release.md at master · PrivateBin/PrivateBin
GitHub⛈️ rain
Als Antwort auf rugk • • •Wow, je mehr ich über die ganze #xz Saga lese, desto beeindruckter bin ich, was für ein unglaublicher Zufall es war, dass das so schnell gefunden wurde 😳
boehs.org/node/everything-i-kn… ist ein lesenswerter Überblick.
bugs.debian.org/cgi-bin/bugrep… gibt einen guten Eindruck, wie vor 5-6 Tagen angefangen wurde, Druck aufzubauen, die kompromittierte Version in Debian hochzuladen. Und wie viel Energie da rein gesteckt wurde.
#infosec #security
Everything I know about the XZ backdoor
boehs.orgMartin Giger
Als Antwort auf rugk • • •sigstore
sigstore