Hi Thierry, thanks for clarifying on this-- On Fri, Nov 10, 2017 at 1:04 PM, Thierry <sage-googlesu...@lma.metelu.net> wrote: > Hi, > > On Fri, Nov 10, 2017 at 12:35:51PM +0100, Erik Bray wrote: >> It seems to me those should be among the most important, if not *the* >> most important tickets to farm out to patchbots across multiple >> platforms. If it made sense to I would set my Windows patchbot to >> prioritize these among all others. >> >> New versions of packages are far more likely to break across >> platform-related issues than, say, updates to non-platform specific >> Python and Cython code. >> >> What is the reason for this, and is there anything I can do to improve >> this situation? > > IIRC, this was for security reasons. I am +1 to allow those tickets to be > patchbot tested, as an option (not by default).
Okay, this *sort of* makes sense. I write "sort of" because it's not immediately clear what the "security" concern is compared to any other ticket. Any change to Sage can contain arbitrary code. While it's true that changes to third-party packages are less immediately transparent than patches to Sage's own codebase, at the end of the day the risk is the same--anyone who can post a ticket to Sage's Trac and who is already "trusted" by the patchbots (and the default is to only run changes by "trusted" authors as it is) can make a risky change. If there were a security risk to a third-party package this doesn't offer any protection to those patchbots in the long term because as soon as the package update is merged those patchbots will start building with the updated package. > I personally run my patchbot within a VM (actually i have to since i have > to emulate 32-bit architecture for Sage Debian Live), so i will volonteer > to test such tickets. I have an automatic way to bootstrap such patchbot > VM (more-or-less every supported versions of Debian and Ubuntu, both 32 > and 64 bits, if there is a strong need, i could work on supporting more > distros and architectures), so i am thinking on providing ready-to-run > patchbots for users that do not want to take risks for their computers, > nor loose time in setting such things up. Right--anyone who is running a patchbot on either a personal machine, or at least not in a VM, is accepting the risk to run arbitrary code on it (which is a risk they should not accept IMO, but there's only so much we can do to protect them from that). As for testing on more distros I do have a plan for that which I hope to enact soon. I have a patchbot running with the Ubuntu-based Docker image that has been working well for some time. There have been a few tiny issues specific to running the tests in Docker, but in general this is no different from testing directly on that distro. So my plan is to make more Sage docker images for other distros (plain Debian, CentOS, Arch, Gentoo, and Alpine are among my top priorities but I'd welcome input on that). Then I can run patchbots with all of them. > Note however that it is not clear what to do with such tickets: by default > a patchbot runs the tests only with respect to the packages installed by > its owner. In this case, if the owner did not install the corresponding > package (which will always be the case if the ticket is about a new > package), the patchbot will report a possibly wrong false positive. I don't understand the issue here--if a package is a dependency of Sage then it will be built, right? This only seems to apply to optional packages. > But, if we want to add an option to let the patchbot install a new package > proposed by some ticket, after testing that ticket, the patchbot will be > in a different state than before to test other tickets, in this situation, > the patchbot will report possibly wrong false negative. Ah, well that's where my improved package uninstallation system comes in: https://trac.sagemath.org/ticket/22510 This actually works very well in my testing so far, but getting the functionality merged is taking some time as there are some difficult prerequisites (e.g. https://trac.sagemath.org/ticket/22509). As a temporary alternative, I suppose that if a *new* package is installed I suppose the patchbot can run `make distclean` after that build. That will slow things down considerably for the next build but...oh well? > So, at the end, we have an issue with our packaging system: there is no > systematic way to uninstall a package. Well, there is now, if it ever gets merged... :) Thanks, Erik -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
