On 8/3/20 2:19 PM, Mark Roszko wrote: >> unfortunately that is a typical thing how problems are getting "solved", >>simply embed the required third party code. From a security perspective >>this is mostly a nightmare as also typically nobody ever touches such >>code again as it "works" for all times. >>Embedded code is quite in no way traceable and make the work of package >>maintainers and of the security teams within Linux distribution even >>more harder [1]. > > But this is also a nightmare. > 1. The main issue is the tool is not a real independent tool, it is only > maintained within sqlite and everyone using it outside of that are > "welcome to" by sqlite but the global library that's available is quite > out of scope of the sqlite maintainers. > 2. Which now leads to the scenario like Arch Linux has. There is no > official repo with lemon. Only a 5-years out of date user repo that is > not exactly helping with that security goal ;) > > But yea, perhaps a configure switch will make this all happy?
Why not use CMake to check to see if lemon is installed on the system and only build for source when necessary? > > > On Mon, Aug 3, 2020 at 2:01 PM Carsten Schoenert > <c.schoen...@t-online.de <mailto:c.schoen...@t-online.de>> wrote: > > Hello Ian, > > Am 03.08.20 um 19:39 schrieb Ian McInerney: > > I have now updated this so that we bundle the lemon parser code > inside > > thirdparty and build it for ourselves (it is only 1 main c file > that was > > released into the public domain). CMake then takes care of all the > > pathing for the template and executable file for the targets. This > > should work on all platforms now with no extra steps. It also > means that > > there is no need to install lemon on dev computers anymore. > > unfortunately that is a typical thing how problems are getting > "solved", > simply embed the required third party code. From a security perspective > this is mostly a nightmare as also typically nobody ever touches such > code again as it "works" for all times. > Please try to avoid this when *ever* possible and look for > alternatives. > For package maintainers a good alternative is to make the use of the > third party code optional. Means that a configure switch should be > available to so on the Linux side we can use the package versions. > > Embedded code is quite in no way traceable and make the work of package > maintainers and of the security teams within Linux distribution even > more harder [1]. > > So if not already the use of the lemon parser is configured in a way I > can chose to use a packaged version please consider to do so. Thank you. > > [1] https://wiki.debian.org/EmbeddedCopies > > -- > Regards > Carsten > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > > > -- > Mark > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
