FedScoop has pointed out that industry vendors have until June 26 to comment on the Cybersecurity and Infrastructure Security Agency's (CISA) draft attestation form for government software providers. The draft Secure Software Self-Attestation Common Form was published Thursday and the window for feedback is 60 days so comments will be accepted through June 26, 2023.
The Cybersecurity and Infrastructure Security Agency on Thursday published a draft attestation form for software providers working with federal government agencies.
The agency launched a 60-day request for comment period, during which industry is able to submit feedback on the document.
This stems from Executive Order 14028 and the Office of Management and Budget's (OMB) M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices. The CISA has requested that interested parties (that's you FOSS projects) review the Secure Software Development Attestation Common Form, and submit feedback.
Redmond and its minions are already on this. Will the FSF, OSI, EFF, SFLC, SFC, and the others step up and be heard?
(Score: 1, Touché) by Anonymous Coward on Monday May 01, @03:11AM (4 children)
s/Feeback/Feedback/
s/Whitehouse/White House/
(Score: 2) by takyon on Monday May 01, @03:53AM
Thanks.
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 3, Touché) by inertnet on Monday May 01, @07:27AM (1 child)
s/speling/spelling
(Score: 1, Touché) by Anonymous Coward on Monday May 01, @07:35AM
It used to be the name of the open source spellchecker:
https://web.archive.org/web/20180314052234/http://www.speling.org/ [archive.org]
Seems to be lost to time now.
(Score: 2) by Freeman on Tuesday May 02, @01:21PM
Just make sure you include the all important .gov on that whitehouse domain.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 5, Interesting) by jb on Monday May 01, @05:08AM (14 children)
The draft form does not even ask for any attestation at all in relation to secure-by-design software development methodologies. All the CISA seems to care about is securing the development *environment* and maintaining a detailed provenance of who contributed what & when (both of which are things that any sane developer has been doing for decades). As such, it's likely to have no positive impact at all (just yet another box to tick). What a wasted opportunity.
As for "interested parties (that's you FOSS projects)", yes I'm sure that many FOSS projects will have something useful to say about the draft (probably much in line with what I've said above), but CISA probably doesn't need to take comments from FOSS projects into account, because Item 2 of the last list on page 2 explicitly excludes FOSS (well, "freeware, open source" which is simultaneously both broader & narrower than "FOSS" ... a bizarre combination!) from requiring the attestation form, so long as the agency obtains the software directly (which in effect only means that implementation firms will make all dependencies be external -- usually a better approach than bundling anyway, as it limits the implementation firm's liability more effectively than any legal disclaimer could).
(Score: 2) by JoeMerchant on Monday May 01, @10:05AM (12 children)
I always found the distinction of "external vs internal" dependency to be a huge farce.
So, you are saying if I link my program this way it's legal, but if I link it that other way (virtually indistinguishable to the vast majority of users) then I am in violation?
The net effect of which, IMO, has been a significant reduction in support of static linking configurations and a proliferation of dll hell management techniques culminating in flat packs, snaps, etc. which, if you stop to think about for a second, aren't that different from static linking....
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by Thexalon on Monday May 01, @10:45AM (10 children)
Yes, that makes perfect sense to me. You get several major things from dynamic linking:
1. It's much easier to separate out what's the library, and what's the executable that's relying on it. With static linking, compiler optimizations and such will intermingle the two.
2. It's much easier to use the library in new ways, because other executables can link to it just as easily as the one that it was originally written for.
3. It's much easier to replace the library with a new version or a fork or a drop-in replacement, so long as it presents the same interface as the original.
For the purposes of licensing, #1 is probably the most important of these. For the purposes of making tinkering possible, which is a big part of the point of FOSS in the first place, #2 and #3 are very big wins as well.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 3, Touché) by JoeMerchant on Monday May 01, @03:23PM (9 children)
>It's much easier to separate out what's the library
For who? People reverse-engineering the binaries? For the other 99.9%, those who read and write source code, the library is equally separated whether it's statically or dynamically linked.
>With static linking, compiler optimizations and such will intermingle the two.
Again, I know people who do reverse engineering (and hate every minute of it). They would seem to represent less than 1 of 1000 software developers / engineers.
>It's much easier to use the library in new ways, because other executables can link to it just as easily as the one that it was originally written for.
Ummm... how are they going to be linking without the headers (a significant part of the source)? Since we're in the domain of open source libraries, how often do you have access to the headers but not the rest of the source?
>It's much easier to replace the library with a new version or a fork or a drop-in replacement, so long as it presents the same interface as the original.
Yeah, you mean it's much easier to break the application by updating the library (aka dll hell in the Microsoft world). There are a _few_ instances where a bug gets fixed in the library and a library drop-in replacement doesn't break other things. In the world I live in, we can't trust that without testing it. Going to the effort of testing is about 10x the effort of a re-compile.
I mean: there are mature library development teams that enable you to upgrade their library without breaking your application most of the time. Qt comes to mind, our code doesn't much care as long as the version of Qt is the same it was compiled to or higher in the same major version - just about 99.9% of the time. I'm sure there are plenty of others, it's just the breakages that become my problem so I see them ALL the time.
I just look at the cluster that is snapd, and wonder: how many applications that "have to be distributed in a container for stability" could have just been statically linked instead?
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by gnuman on Monday May 01, @04:33PM (5 children)
For distro maintainers.
Actually this is by design for enterprise distros that provide ABI compatibility guarantees for a 10+ year lifecycle. Sure, some things could be excluded, but many, many things are provided with this guarantee.
I suggest if you are butthurt about this, you should just go with a static linked language like Go, that is not really supported by any OSS distro.
(Score: 4, Touché) by JoeMerchant on Monday May 01, @05:21PM (4 children)
There's no butthurt about it, unless you're talking about the recent proliferation of container based solutions to dynamic link based instabilities. Those same distro maintainers, building another clever band-aid solution to a problem that was created by yet another bit of cleverness. My solution has been to uninstall snapd and everything that comes with it, and Ubuntu seems to have gotten a lot of that from the user community, but flatpack is right around the corner waiting to be the same hammer for driving in a screw that could have just been driven with a screwdriver in the first place.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by gnuman on Thursday May 04, @06:30PM (3 children)
That was definitely not what these solutions are aiming for. They are meant to solve the problem of
1. don't change anything
2. except I want the latest of this program I use.
(Score: 2) by JoeMerchant on Thursday May 04, @06:51PM (2 children)
More often I find them being used for:
This *(#% program won't run in the most recent release, so: give it a container with what makes it happy (from older releases, sometimes much older) and let it run within my otherwise more up-to-date system.
They also seem to be a tool for the lazy: Got the thing to work once, never need to touch it again - just put it in a container and it will work forever.
Of course, they can also be used to put bleeding edge apps and libraries into an otherwise older, more stable system.
Any way you slice it: it's version proliferation - you'll be running multiple versions of your shared libraries whether they're older without the latest patches, or newer without significant testing time.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by gnuman on Thursday May 04, @09:14PM (1 child)
This is true. Also the case "run new app on stable, supported system".
This depends on a lot of things. But you can have similar base system with additional dependencies on top. You can run same supported kernel, same openssl, same glibc, and then stuff on top. Of course, you can't fix broken security practices. I do agree that containers allow for that.
I do agree with you, but I'm also not as pessimistic about it.
(Score: 2) by JoeMerchant on Thursday May 04, @10:07PM
They are another type of tool, and they usually work, but also introduce plenty of ways to be misused.
Plus, they are slow loading as compared to straight dynamically linked programs. Early days that was a noticable advantage of dynamic over static linking: initial load and run times. The difference static to dynamic linked run times today is pretty trivial, but snaps can be noticably slower...
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 4, Informative) by rpnx on Monday May 01, @09:35PM (2 children)
Static linking isn't a violation of LGPL as long as your provide object files that enable re-linking the executable statically with a modified version.
(Score: 2) by JoeMerchant on Monday May 01, @09:48PM (1 child)
Makes sense to me, and LGPL is what I try to stick to.
For added fun, try talking with a closed source developer who scripts everything so they can call GPL code from their code...
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 0) by Anonymous Coward on Wednesday May 03, @07:07AM
(Score: 2) by GloomMower on Monday May 01, @02:51PM
> I always found the distinction of "external vs internal" dependency to be a huge farce.
When I hear external vs internal dependency, I usually think organizational wide. Doesn't really matter how it is linked. It is if we are using a vendor or open source library. Or if it is a library from within the organization.
(Score: 2) by krishnoid on Monday May 01, @03:37PM
Maybe it would have been better to have input from multiple interested parties [schlockmercenary.com] on what "securing" the supply chain actually means, and from what kinds of threats.
(Score: 2) by VLM on Monday May 01, @08:52PM
Which FOSS projects have to fill out this form WRT providing feedback about the form and process?
I'm curious because I actually read the form and contemplated having to fill one out for stuff I've written.
I found on page 7, Section I, and I quote:
For a good time, see also page 2, the list of software that does not require self-attestation, which pretty much repeats page 7 Section I's verbiage above.
So as I read it I can't fill out this form for anything I've got on github thats FOSS licensed.
Is the "FOSS controversy" over another different form that applies to FOSS, because this form literally does not?
WRT FOSS stuff I've written if the feds wanted to use it in a non-FOSS sense, perhaps using a BSD license, etc, thats fine, as per page 9 the feds think a reasonable billing time is 3 hours and 20 minutes to fill out the form, I can deal with that, simply make a donation to me for 3:20 billable hours at a reasonable hourly rate, not a problem.