> Yes there is > You’re thinking of signing authorities. No, I don't. I was asking for a list of authorities that you would consider authoritative (which inva

> Yes there is > You’re thinking of signing authorities. No, I don't. I was asking for a list of authorities that you would consider authoritative (which invariably will be subjective, but would be interesting nonetheless). > You could also flip The argument on its head and say why should every committee that throws a specification up be considered a standards authority when half the time specifications are incomplete, contradict other specifications or flat out don’t work. Oh sure, specifications always suck™. But that is unfortunately quite independent from the organisation, happens all the time with ISO standards, IETF RFCs, or whatever you would consider "recognised" bodies. > I have no interest to waste any more time explaining the difference between a standard and a specification to people who are unwilling to consider there might be a difference. You haven't explained anything. All you have been saying in this thread is "I don't recognise the Reproducible Builds project as a standards authority, because I only believe in my personal list of authorities that I won't reveal". The point is, a standard does not become a standard because it is published by a "competent authority". A standard becomes a standard when people in the respective field converge on using it. And yes, there are of course certain fields where this convergence can be enforced e.g. through local law, professional associations etc. However, software development is generally not one of these fields: who will reprimand you if you write a C compiler that does not follow ISO/IEC 9899, or in this case one that does not respect SOURCE_DATE_EPOCH?