Honestly, if I had to start from scratch in my own company, I would pick zulip. That is thread friendly for real, for proper async communication. Slack threads were bolted on as a feature, and it shows. I know that in 2 this is not a problem, but the way that - for example - notifications work for threads when you have 10s (or 100s) of threads is a pain. Finding back threads you were involved with is a huge pain.

For certain things, makefiles are great options. For others though they are a nightmare. From a security perspective, especially if you are trying to reach SLSA level 2+, you want all the build execution to be isolated and executed in a trusted, attestable and disposable environment, following predefined steps. Having makefiles (or scripts) with logical steps within them, makes it much, much harder to have properly attested outputs.

Using makefiles mixes execution contexts between the CI pipeline and the code within the repository (that ends up containing the logic for the build), instead of using - centrally stored - external workflows that contains all the business logic for the build steps (e.g., compiler options, docker build steps etc.).

For example, how can you attest in the CI that your code is tested if the workflow only contains "make test"? You need to double check at runtime what the makefile did, but the makefile might have been modified by that time, so you need to build a chain of trust etc. Instead, in a standardized workflow, you just need to establish the ground truth (e.g., tools are installed and are at this path), and the execution cannot be modified by in-repo resources.

That doesn't make any sense. Nothing about SLSA precludes using make instead of some other build tool. Either inputs to a process are hermetic and attested or they're not. Makefiles are all about executing "predefined steps".

It doesn't matter whether you run "make test" or "npm test whatever": you're trusting the code you've checked out to verify its own correctness. It can lie to you either way. You're either verifying changes or you're not.

You haven't engaged with what I wrote, of course it doesn't make sense.

The easiest and most accessible way to attest what has been done is to have all the logic of what needs to be done in a single context, a single place. A reusable workflow that is executed by hash in a trusted environment and will execute exactly those steps, for example. In this case, step A does x, and step B attests that x has been done, because the logic is immutably in a place that cannot be tampered with by whoever invokes that workflow.

In the case of the makefile, in most cases, the makefile (and therefore the steps to execute) will be in a file in the repository, I.e., under partial control of anybody who can commit and under full control of those who can merge. If I execute a CI and step A now says "make x", the semantic actually depends on what the makefile in the repo includes, so the contexts are mixed between the GHA workflow and the repository content. Any step of the workflow now can't attest directly that x happened, because the logic of x is not in its context.

Of course, you can do everything in the makefile, including the attestation steps, bringing them again in the same context, but that makes it so that once again the security relevant steps are in a potentially untrusted environment. My thinking specifically hints at the case of an organization with hundreds of repositories that need to be brought under control. Even more, what I am saying make sense if you want to use the objectively convenient GH attestation service (probably one of the only good feature they pushed in the last 5 years).

Usually, the people writing the Makefile are the same that could also be writing this stuff out in a YAML (lol) file as the CI instructions, often located in the same repository anyway. The irony in that is striking. And then we have people who can change environment variables for the CI workflows. Usually, also developers, often the same people that can commit changes to the Makefile.

I don't think it changes much, aside from security theater. If changes are not properly reviewed, then all fancy titles will not help. If anything, using Make will allow for a less flaky CI experience, that doesn't break the next time the git hoster changes something about their CI language and doesn't suffer from YAMLitis.

You're correct. It's absolutely security theater. Either you trust the repository contents or you don't. There's no, none, zilch trust improvement arising from the outer orchestration being done in a YAML file checked into the repo and executed by CI instead of a Makefile also executed by CI.

What's the threat model Wilder is using exactly? Look, I'm ordinarily all for nuance and saying reasonable people can disagree when it comes to technical opinions, but here I can't see any merit whatsoever to the claim that orchestrating CI actions with Make is somehow a security risk when the implementations of these actions at some level live in the repo anyway.

See my other comment.

> when the implementation of these actions at some level live in the repo anyway

This is the false assumption. You can standardize that not to happen, and you can verify at runtime that's not the case. You can control admission of container images for example, restricting those that were built by your workflow X (the approved, central, controlled, standard one) and reject anything else. You do this via build provenance attestation.

With makefile I don't know how you can achieve standard and centrally manageable (and verifiable) instructions (which are part of SLSA).

Maybe a concrete example would help.

> With makefile I don't know how you can achieve standard and centrally manageable (and verifiable) instructions (which are part of SLSA).

The way I'm thinking about it, we distinguish instructions from policy. Policy, of course, has to be imposed from outside a package somehow, but the instructions taken within policy seem like things that should evolve with it. For example, "no network access" might be an externally enforced policy. Another might be limitations of dependencies, enforced by making exceptions to the previous policy.

But in the end, you have to do something. Are you suggesting a model in which a project's entire test suite lives in a separate repository with an access control policy that differs from that project's so that the project's authors can't cheat on test coverage or pass rate?

Sure, you can do that, but the instructions for running those tests still have to live somewhere, and a makefile in that test repository seems like as good a place as any.

A classic example would be build (container build) images instructions. Of course, other examples are running a security static analysis, running tests, or whatever other standard practice is desidered for security.

Say that you build 100 images, each with its own repository where there is the code, there is the Dockerfile etc. Now, if you build images with "make build", it means that ultimately the actual command line flags for the build command are going to be in the Makefile, inside each repository. These flags could include flags like --cache-from, build arguments, --add-host, or many other flags that may not be desirable in an organization. Imagine what the workflow file would like for such a case: you have your in-repo CI file that clones the repo, and then executes make test, make build, make push, etc. Do you know if make push sent the PCI registry secret somewhere else on the internet? Do you know what exactly flags were used to build? Not really, you need to trust the code inside the repo to at most collect this information, and how do you know it was not tampered or spoofed?

Compare it with the following scenario: All 100 repos at some point in that CI invoke an external workflow, which contains instructions to build images, push them to the registry (and run tests before, whatever). This can obviously also be a combination or workflows, I am saying one for simplicity. This workflow (or workflows) at the end produces an attestation, including provenance data and about what is run. It can do so reliably, because the instructions of what had to be done are within its own context. There is no input that comes from outside (e.g., the repository) that determined build flags or instructions, outside of what the workflow exposed (e.g., few variables).

In the second case, I can then use a policy that restrict images that have attestation and that were built by my workflow(s) that contain standard and deterministic instructions. This way I know that no image was built using weird build flags, including strange dependencies, maybe tampering with network and DNS (in makefile I can write whatever) or local docker cache, etc. I know this because a standard workflow was executed in a fresh, "sterile" environment with a standard set of instructions, that can't be changed or tampered by those controlling the repository content.

Note that all of the above is solely concerned with being able to make security statements on the build artifact produced, not on the context of the build (e.g., no network access).

That's a great point. If we keep following the requirement for attestation to its logical conclusion we would end up replicating the entire server running the repository at the source, then the cycle repeats

Not really, that's the point. Reusable workflow, in a tightly controlled repos avoid exactly what you are saying and they are a fairly standard practice (if anything, also to avoid having 200 versions of CI instructions). You can also verify attestations provenance by enforcing attestation performed via that particular, approved workflow, which is not security theater, it's actual real controls.

I have been experiencing this on my 2k monitors as well (Also BENQ). I tried every "fix" under the sun, eventually it stops after enough voodoo (reboots, unplugs) and cursing.

One of the many random issues on the OS with the best UX in the world (lol). Like music sometimes stopping and sometimes switching to speakers when turning off Bluetooth headphones, mouse speed going bananas randomly requiring mouse off and on, terminal app (iterm2) reliably crashing when I dare to change any keybinding, and many other things that never happened in years of working on Linux.

Anthropologically speaking these statements about human fundamentals (or "human nature") end up falling flat. There have been plenty of societies organized in ways such that private property was irrelevant when existing at all.

I suggest "Debt" from David Graeber for a great dissertation of this topic (which is not the core topic, but definitely touched).

All of this without considering that private property of means of production is different from private property in general.

Guess which country had never any interest in a strong (politically and militarily) Europe, to maintain the world hegemony?

A Europe with an independent defense is dangerous competition for the US. Maybe it means that some international trade will be done in Euro. Maybe it means foreign policies in Europe's interests.

These are all (both mine and yours) opinions, and we will need studies to see what's what. That said, my opinion is that not everything is a software development pipeline and needs to be efficient with short feedback loop.

To me what you say:

> will mean that they start seeing rewards for their efforts much faster

sounds essentially a negative. This leads to rewards-chasing and a habit of obtaining result without an appropriate amount of effort. This means that many won't even ever discover their passions or what they are good at. Putting the effort is a necessary step to grow. In other words, will any kid with this machine ever draw something from scratch, after they got used to having something much better than what they could do (at least at the beginning) by hand?

All of this without even mentioning the impact of creativity, where instead of having to think/conceive stuff you have a technology that does that for you after a minimal input, rehashing what has been already thought.

My wish is that tech people just realized that the world is better off without their tech in most cases and stopped thinking that everything in the world needs some tech to "help" (which of course is really a way to make money).

Working should be a free choice (we can discuss about how much freedom exists for many people), and should always be paid. There is nothing wrong if a prisoner chooses to enagage in (fairly paid) labor. But if they are not free to do so, then they are slaves, not workers.

Prisoners already lack freedom in many aspects. "Sitting on their asses" like if they were sipping cocktails on a beach is a bit a misrepresentation don't you think? I wouldn't exchange the possibility to move and do what I want for possibly any amount of money, nor for being able to "sit on my ass" in that sense. Would you?

Besides the moral arguments - which I will say, they are so obvious that it feels incredible even having to discuss why enslaving prisoners is wrong - you can make economic arguments. For example, that having cheap or borderline unpaid labor compresses the salary in that market, or that this system creates a dysfunctional incentive to increase prison population for private profits.

Maybe that's why the US is one of the countries with the highest incarcerated population in the world. The highest among western and larger countries.

I understand though there is a cultural barrier. I am from Europe and in most countries here prison has a rehabilitation purpose, which is what most benefits society, and prisons are not private entities.

They are not free to do that when there is a duopoly and in most countries the platforms don't even allow competitors for that market (especially true for Apple).

Seriously, playing the "free market" card in the tech (especially mobile) space is really brave.

No one is forcing people to make businesses that release ios apps. A business could be based off of a Windows app. Or they could even not have an app and do business through an existing one like Discord.

Reality forces people to do that. When 90% of people do whatever they use programs for via mobile, you (as in, a business who wants to succeed) are forced to make an android and an iOS app.

Plenty of apps are Android only or iOS only. The only "force" is that businesses see these platforms as worth it to make enough money to be a return on investment.

Yes, accessing more than half of the market in US and about 25% of the worldwide one is surprisingly something businesses want to do.

Of course businesses do it because it's profitable. The point is that the market is ridiculously controlled while you are pretending that businesses can make _free_ choices, while for many of them they are not free or in some cases not even choices.

In my organization we have RFCs, PRDs, ADRs etc. and I would say that the process is fairly broken. That said, I think what you mention is an important but not the only failure mode of a proposals process.

In some cases I have seen, people use RFCs to steamroll decisions when they are the only stakeholders. Here the waste comes from the fact that the proposal becomes just a bureaucratic step or a way to diffuse responsibility.

In the case you mention (which I have seen many times) I would say the general issue is that the goals and the constraints are not qualified sufficiently. If that's the case, then there are only 2 cases: there is an objective way to measure if an objection or comment makes sense or not, or it is subjective. If it's objective, then consensus is easy to reach, if it's subjective, it needs to be acknowledged and usually the decisions falls on those who are responsible for the outcome (e.g., the team who needs to maintain or build the thing).

Of course, the debate can move to constraints, goals or even ways to measure, but these are generally more straightforward.

Have you worked at an organization without RFCs, ADRs, etc? The alternative is really just the wild west and whatever politics or pull a person has. RFCs and ADRs are good in the sense that they document _something_ even if the document is junk it's better than an assumption.

Really though it's the organization (and people) that makes or breaks anything.

I generally agree that it's better than nothing. That said, it's possible that sometimes these processes become bureaucratic shields for avoiding certain processes.

For example, a broken RFC process might be a way not to actually involve and gain useful consensus from people (I.e., I did my presentation during the weekly session, nobody had feedback), which instead would be the natural way in a company without that process.

100% agree that it's all about the people (and the culture shaped by them).

I feel what you are proposing is the worst of both worlds.

The company still needs to pay a full office (decreasing chances that money will be used for home office benefit or raises), people are still forced to live somewhat close to the office, not realizing the biggest benefit of remote work: living where you want, close to the people you care and freeing up money and time.

If working together really helps, it's enough that those who think that coordinate and agree on days to go to the office. If nobody agrees, than maybe the benefits are only perceived or subjective?

I will be honest, I believe that lots of people go to the office because their 9-5 (+ commute) job made it impossible for them to maintain and cultivate social relationships outside work, which means they see the office as their attempt to escape loneliness. I am not saying that's everyone, but that for many people is the case and that explains people non-stop interrupting, walking in on others, chatting etc., which is quite common in office environments.

That said, I think that remote work needs also a few key elements to succeed:

- a remote culture in the company (e.g., everyone understands flexibility in terms of working time, meetings are online-first, documentation and async work culture, etc.) - a good space to work at home. I can't imagine working on a stool and a laptop like some people were forced to do during covid. - discipline (e.g., not let work time bleed into personal time, blocking time etc.) - good social relationships with friends/family. It can be very alienating otherwise.