Hi Paul, Am Donnerstag, dem 20.04.2023 um 18:07 +0200 schrieb Paul Gevers: > [...] > > Since I already followed the Debian Policy and included the missing sources > > in > > debian/missing-sources, I felt that shipping the 3rdparty directory in > > debian/missing-sources/3rdparty would be a good intermediate solution. > > But you added a more files than you have in testing (including jquery.js).
Yes, because 3.6.1 was the first version after 3.5.2 that removed those 3rdparty Javascript files. I noticed it after I had uploaded the package. I corrected this problem in 3.6.2-1. > > If you > > insist I can repack the tarball, add the 3rdparty directory and remove it > > from > > debian/missing-sources but in the end it would not make any difference. > > Huh? I wasn't asking you to do that. I was asking you to use packaged > binaries as a dependency. > > > Openrefine is a desktop application which only runs on your own computer. > > You know, now I know. Does the security team also know? Should they really? I am a member of the security team. It is on my radar. > > > If > > you insist I can depend on libjs-jquery and replace the local copy with a > > symlink but I feel this would be an example of over-engineering without any > > real value to our users in this specific case. > > That argument holds for a lot of things we do. What I try to say is that > there's a price we pay in our community too by not doing it. In this > case: tracking embedded versions. Because of the popularity of things > like jquery they are embedded a lot and we're trying to track them *and* > remove them. Just to clear, I wasn't *only* talking about jquery.js, but > also about the others that are covered by binaries in our archive. Even > if upstream added stuff back, I would still recommend you to link (and > depend on) the files shipped in e.g. libjs-jquery. I know what I talking > about, my upstream cacti ships a lot of embedded libraries too; I do my > best to remove things that we already ship in Debian. My upstream > complained once in a while that my versions are wrong; I still believe > it's the right thing to do in a distribution like Debian. I think they > are starting to see the value of our side too. > > Lintian is telling you that too: > https://udd.debian.org/lintian/?packages=openrefine As I had explained in my previous reply, there is no security impact. Cacti is a network application and can be accessed remotely by different parties. Instead openrefine is a privacy focused standalone application. Keeping your data on your own computer is a feature here. The security team would triage any Javascript CVE for openrefine as either unimportant or minor because openrefine is intended to be used for local and single person usage. Code deduplication is also not a problem, JS files are often small. On the other hand there is a huge downside for all those Javascript system libraries. Even minor changes may break existing applications, APIs are not stable, upstream is unable to help you if you diverge from their version. And then there is another point which is often neglected in Debian discussions: developer time. We waste too much time for over-optimizations and often neglect user experience and maintainability aspects. It seems we treat every computer language and every package as it was C only and try to use always the same hammer because everything looks like a nail. I believe it is important to differentiate from time to time. Regards, Markus
signature.asc
Description: This is a digitally signed message part
