Re: speed-dreams-2.3.0: how to handle bundled jar files in spec file ?
I think it is better to do without the track editor for the time being and to use SD with the option -DOPTION_TRACKEDITOR:BOOL=OFF to compile. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On 24-07-2023 17:38, Julio Faracco wrote: I also need access to the packager group to claim maintainership. Who could provide it to me? The route you are looking at is described in "Adopting an orphaned or freshly retired package": https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#adopting -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On Mon, Jul 24, 2023 at 11:45:26AM -0400, Solomon Peachy via devel wrote: > On Mon, Jul 24, 2023 at 04:00:21PM +0100, Daniel P. Berrangé wrote: > > If I have a USB flash stick I plug in every day, it shouldn't ask me > > about that after the first time I use it. > > Based on this "threat model" all an attacker has to do then is > snag/modify/replace your existing drive and then they can pwn your > system. That's probably much easier to accomplish than getting you to > insert a previously-unseen device (the latter has a lot of awareness > around it, but the "of course I trust this one, it's mine!" will get you > pwned.) While in-person attackers are real, IMHO that are not the big risk factor for the general populace. I wasn't claiming this was a perfect solution, just that it addresses some easy low hanging fruit, where you have no clue what will be on a new drive you receive (whether purchased online, or as a swag at a trade show, etc). > (Besides, how are you to distinguish the exact stick? Most of the stuff > I have lying around here reports the same generic vendor/product/serial > number. And drive/volume labels are notoriously unreliable.) Yes there are some lame vendors, that don't burn unique serials, which will make it imperfect. IMHO it is still credible to use the vendor/product/serial despite that. > > If I acquire a new USB flash stick I've never plugged in before, I > > don't want it auto-mounting before I can wipe & reformat it. > > Honestly, what makes more sense to me is treat this whole thing purely > as a usability problem. Upon insertion, prompt the user to "mount, > mount reat-only, check, ignore", because at least then we'd get an > really easy method of fscking a disk without having to do the whole > unmount dance. It also provides a mechanism to supply user feedback (eg > showing fsck results, or the XFS case where you _have_ to mount the > filesystem to replay the journal before an fsck can be safely run) If you prompt a user every single time, all that results is training the user to press 'yes' without looking. To be useful the prompts need to only happen in unusual circumstances, that are infrequent enough to avoid training an instinctive response. > Again, let's be realistic about the threat models here -- the > overwhelmingly common situations are accidental corruption due to > improper shutdown/ejection, and malicious files on a well-formed > filesystem (eg ransomware or something that's banking on users having we > passwordless sudo in place, or curl https://url/setup.sh | sudo bash) Accidental corruption is indeed important, and wouldn't be solved by prompting. Protecting against that I think requires taking the libguestfs approach of mounting in an isolated guest OS kernel. In terms of malicious files, I think that not trusting newly seen devices is a valid strategy. There's plenty of documented cases where new devices had malware pre-installed. Re-formatting newly seen devices means the user only needs worry about their own usage from that point onwards, bringing in malware. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
License correction for strawberry
Hello, The license for strawberry has been corrected and converted to SPDX from "GPLv2 and GPLv3+ and LGPLv2 and ASL 2.0 and MIT and Boost" to "MIT AND Apache-2.0 AND GPL-2.0-or-later AND GPL-3.0-or-later". Refer to the spec file for the license breakdown by source files, which should now correspond to the latest tarball contents. Cheers, Ondrej ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
speed-dreams-2.3.0: how to handle bundled jar files in spec file ?
Hi, i want to package the current version of speed-dreams 2.3.0, but i noticed that jar files for the trackeditor are included in the package, but they already exist in the system. compilation error: Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/martin/rpmbuild/BUILDROOT/speed-dreams-2.3.0-1.fc38.x86_64 error: Installed (but unpackaged) file(s) found: /usr/bin/bsh-2.0b4.jar /usr/bin/jdom-1.1.3.jar /usr/bin/jgoodies-common-1.8.1.jar /usr/bin/jgoodies-looks-2.5.3.jar In the file src/tools/trackeditor/CMakeLists.txt from line 181 to line 230 the jar files are copied as you can see. https://sourceforge.net/p/speed-dreams/code/HEAD/tree/trunk/src/tools/trackeditor/CMakeLists.txt#l181 do i have to use the jar files from the fedora packages now ? bsh-2.1.0-8.fc38.noarch jdom-1.1.3-32.fc38.noarch jgoodies-common-1.8.1-17.fc38.noarch jgoodies-looks-2.7.0-7.fc38.noarch that is, remove the jar files from the speed-dreams package and link to the Fedora jar files in the spec file. Regards Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
