[sage-devel] sage-2.8.7
Hi, I have released sage-2.8.7. You can upgrade via sage -upgrade or download the source from sagemath.org. Binaries will be available tomorrow. For a list of patches see: http://sagemath.org/announce/sage-2.8.7.txt I huge number of people helped a great deal with this release, especially Carl Witty, Craig Citro, Robert Bradshaw, Joel Mohler, Michael Abshoff, Martin Albrecht, and *many* other people. Thanks! William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: random polynomial generation
Hi and thanks for your quick answers! Hi Stephen, This is not an exact function. The only guarantee we have is that we will get a polynomial with total degree of *at most* 4 and total number of terms is *at most* 9. You're right, in such a big field the coefficient is almost always nonzero. The problem is in the degrees: we don't check for repetitions when generating them (we don't care). As you know, we often view multivariate polynomials as dictionaries with the degrees as keys and the coefficients as values. The functions works simply (with parameters 4 and 9): 1) generate 9 random tuples of for the degrees. The only requirement we have is that the sum of the element in these tuples must not exceed 4. Repetitions are allowed. 2) Generate 9 coefficients. 3) Create a dictionary where the keys are the degree tuples and the values are the coefficients. Repetitions are discarded and that is how we end up with a polynomial with less than 9 terms. 4) Create a polynomial from this dictionary and return it. Hi didier, the implementation does not return a polynomial of a total degree of at most 4, but a polynomial of total degree of at most 4/2 = 2 in x and in y. If I change the total degree to 5, nothing happens, since 5/2 = 2. This might be a bug in the implementation. However I am happy with this behaviour and maybe there should be the option for choosing the total degree or the degree in every variable. Furthermore I am not happy with this implementation in general. In step 1.) you do not care about repetitions. This sounds reasonible since repetitions are part of randomness. Later in step 3) you do care about repetetions and summarise them under the value 0. If the value 0 gains the same importance as all other values in the corresponding set of values, than the multiple occurance of 0 is a repetition, too. I am quite new in SAGE and have no idea how sage code looks like, but I will have a look and see if I can do some changes :-) Cheers, Steffen --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.7
This version does not upgrade or install on suse 9.1 amd64. I would not make it a priority since these machines are due to be upgraded, but thought I'd let you know. However, it does not install on suse 10.2 either! In case this helps: sage: An error occurred while installing flint-0.2.p4 Please email sage-devel http://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/wdj/sagefiles/sage-2.8.7/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/wdj/sagefiles/sage-2.8.7/spkg/build/flint-0.2.p4 and type 'make'. Instead (using bash) type source local/bin/sage-env from the directory /home/wdj/sagefiles/sage-2.8.7 in order to set all environment variables correctly, then cd to /home/wdj/sagefiles/sage-2.8.7/spkg/build/flint-0.2.p4 make[1]: *** [installed/flint-0.2.p4] Error 1 make[1]: Leaving directory `/home/wdj/sagefiles/sage-2.8.7/spkg' real6m3.763s user5m22.186s sys 0m33.797s [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 ./sage -- | SAGE Version 2.8.7, Release Date: 2007-10-15 | | Type notebook() for the GUI, and license() for information.| -- /usr/bin/env: sage.bin: No such file or directory /home/wdj/sagefiles/sage-2.8.7/local/bin/sage-sage: /home/wdj/sagefiles/sage-2.8.7/local/bin/sage-ipython: sage.bin: bad interpreter: No such file or directory [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 On 10/16/07, William Stein [EMAIL PROTECTED] wrote: Hi, I have released sage-2.8.7. You can upgrade via sage -upgrade or download the source from sagemath.org. Binaries will be available tomorrow. For a list of patches see: http://sagemath.org/announce/sage-2.8.7.txt I huge number of people helped a great deal with this release, especially Carl Witty, Craig Citro, Robert Bradshaw, Joel Mohler, Michael Abshoff, Martin Albrecht, and *many* other people. Thanks! William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.7
On Oct 16, 4:26 pm, David Joyner [EMAIL PROTECTED] wrote: Hi David, This version does not upgrade or install on suse 9.1 amd64. As far as I can tell Suse 9.1 AMD64 ships with gcc 3.3, which is not C99 conform. So flint won't build, you need at least gcc 3.4 or higher. I would not make it a priority since these machines are due to be upgraded, but thought I'd let you know. However, it does not install on suse 10.2 either! In case this helps: Could you please post the lets say 60-100 lines before that? Cheers, Michael sage: An error occurred while installing flint-0.2.p4 Please email sage-develhttp://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/wdj/sagefiles/sage-2.8.7/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/wdj/sagefiles/sage-2.8.7/spkg/build/flint-0.2.p4 and type 'make'. Instead (using bash) type source local/bin/sage-env from the directory /home/wdj/sagefiles/sage-2.8.7 in order to set all environment variables correctly, then cd to /home/wdj/sagefiles/sage-2.8.7/spkg/build/flint-0.2.p4 make[1]: *** [installed/flint-0.2.p4] Error 1 make[1]: Leaving directory `/home/wdj/sagefiles/sage-2.8.7/spkg' real6m3.763s user5m22.186s sys 0m33.797s [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 ./sage -- | SAGE Version 2.8.7, Release Date: 2007-10-15 | | Type notebook() for the GUI, and license() for information.| -- /usr/bin/env: sage.bin: No such file or directory /home/wdj/sagefiles/sage-2.8.7/local/bin/sage-sage: /home/wdj/sagefiles/sage-2.8.7/local/bin/sage-ipython: sage.bin: bad interpreter: No such file or directory [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 On 10/16/07, William Stein [EMAIL PROTECTED] wrote: Hi, I have released sage-2.8.7. You can upgrade via sage -upgrade or download the source from sagemath.org. Binaries will be available tomorrow. For a list of patches see: http://sagemath.org/announce/sage-2.8.7.txt I huge number of people helped a great deal with this release, especially Carl Witty, Craig Citro, Robert Bradshaw, Joel Mohler, Michael Abshoff, Martin Albrecht, and *many* other people. Thanks! William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: andlinux
Bill Page wrote: Are you using any special (non-US) keyboard configuration? Standard US-keyboard on a laptop, but the Windows is Dutch! I'm not very familiar to Windows, but I need this laptop for some navigational programs, only available under Window$! There are some dead keys I suppose, after ' you have to hit the space bar. Maybe you get used to it after a time. Don't know how to alter this behavior. But I'm happy to announce that upgrading to sage-2.8.7 went smoothly. Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.7
On 10/16/07, mabshoff [EMAIL PROTECTED] wrote: On Oct 16, 4:26 pm, David Joyner [EMAIL PROTECTED] wrote: Hi David, This version does not upgrade or install on suse 9.1 amd64. As far as I can tell Suse 9.1 AMD64 ships with gcc 3.3, which is not C99 conform. So flint won't build, you need at least gcc 3.4 or higher. I would not make it a priority since these machines are due to be upgraded, but thought I'd let you know. However, it does not install on suse 10.2 either! In case this helps: Could you please post the lets say 60-100 lines before that? I'm not sure if this is enough or not, but I hope it helps: sage/libs/linbox/linbox.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/libs/linbox/linbox.pyx sage/matrix/matrix_modn_dense.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/matrix/matrix_modn_dense.pyx sage/matrix/matrix_modn_sparse.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/matrix/matrix_modn_sparse.pyx sage/matrix/matrix_mod2_dense.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/matrix/matrix_mod2_dense.pyx sage/matrix/matrix_mpolynomial_dense.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/matrix/matrix_mpolynomial_dense.pyx sage/rings/finite_field_givaro.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/rings/finite_field_givaro.pyx sage/libs/singular/singular.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/libs/singular/singular.pyx sage/gsl/dwt.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/gsl/dwt.pyx sage/gsl/gsl_array.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/gsl/gsl_array.pyx sage/gsl/ode.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/gsl/ode.pyx sage/gsl/fft.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/gsl/fft.pyx sage/gsl/interpolation.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/gsl/interpolation.pyx sage/gsl/callback.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/gsl/callback.pyx sage/gsl/probability_distribution.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/gsl/probability_distribution.pyx sage/gsl/integration.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/gsl/integration.pyx sage/rings/real_double.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/rings/real_double.pyx sage/rings/complex_double.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/rings/complex_double.pyx sage/rings/real_rqdf.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/rings/real_rqdf.pyx sage/rings/complex_number.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/rings/complex_number.pyx sage/misc/sagex_ds.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/misc/sagex_ds.pyx sage/libs/symmetrica/symmetrica.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/libs/symmetrica/symmetrica.pyx sage/media/channels.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/media/channels.pyx sage/ext/sig.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/ext/sig.pyx sage/ext/arith.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/ext/arith.pyx sage/ext/arith_gmp.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/ext/arith_gmp.pyx sage/ext/multi_modular.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/ext/multi_modular.pyx sage/structure/coerce.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/structure/coerce.pyx sage/structure/coerce_dict.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/structure/coerce_dict.pyx sage/modular/congroup_pyx.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/modular/congroup_pyx.pyx sage/ext/arith.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/ext/arith.pyx sage/structure/element.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/structure/element.pyx sage/categories/morphism.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/categories/morphism.pyx sage/categories/functor.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/categories/functor.pyx sage/categories/action.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/categories/action.pyx sage/modules/module.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/modules/module.pyx sage/rings/ring.pyx -- /home/wdj/sagefiles/sage-2.8.7/local//lib/python/site-packages//sage/rings/ring.pyx
[sage-devel] Re: sage-2.8.7
On Oct 16, 5:46 pm, David Joyner [EMAIL PROTECTED] wrote: On 10/16/07, mabshoff [EMAIL PROTECTED] wrote: On Oct 16, 4:26 pm, David Joyner [EMAIL PROTECTED] wrote: Hi David, Hi David, This version does not upgrade or install on suse 9.1 amd64. As far as I can tell Suse 9.1 AMD64 ships with gcc 3.3, which is not C99 conform. So flint won't build, you need at least gcc 3.4 or higher. I would not make it a priority since these machines are due to be upgraded, but thought I'd let you know. However, it does not install on suse 10.2 either! Okay, but is seems that is unrelated to flint, because the error is caused by cython's pari glue code (see below) In case this helps: Could you please post the lets say 60-100 lines before that? I'm not sure if this is enough or not, but I hope it helps: SNIP that was plenty ;) running install running build running build_py running build_ext building 'sage.libs.pari.gen' extension gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/home/wdj/sagefiles/sage-2.8.7/local//include -I/home/wdj/sagefiles/sage-2.8.7/local//include/csage -I/home/wdj/sagefiles/sage-2.8.7/devel//sage/sage/ext -I/home/wdj/sagefiles/sage-2.8.7/local/include/python2.5 -c sage/libs/pari/gen.c -o build/temp.linux-x86_64-2.5/sage/libs/pari/gen.o -w sage/libs/pari/gen.c: In function '__pyx_f_py_3gen_3gen_factor': sage/libs/pari/gen.c:19784: internal compiler error: in merge_alias_info, at tree-ssa-copy.c:235 Please submit a full bug report, with preprocessed source if appropriate. gcc blows up, there is little we can do about that. Please check if there are updates compilers available for SuSE 10.2. If not you can either install your own gcc from sources or install the optional gcc.spkg. In that case you need to modify $LD_LIBRARY_PATH to also include $SAGE_LOCAL/lib64 before $SAGE_LOCAL/lib on an AMD 64 box. I will have a look at sage/libs/pari/gen.c:19784 and see if there is anything suspicious in that area. Could you please open a ticket along the lines of paru/gen.c causes internal compiler error on OpenSuSE 10.2 and give us uname -a and gcc -v. Cheers, Michael See URL:http://www.suse.de/feedback for instructions. error: command 'gcc' failed with exit status 1 sage: There was an error installing modified sage library code. real0m12.882s user0m8.653s sys 0m1.840s ERROR installing SAGE real10m8.202s user7m25.064s sys 0m12.473s sage: An error occurred while installing sage-2.8.7 Please email sage-develhttp://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/wdj/sagefiles/sage-2.8.7/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/wdj/sagefiles/sage-2.8.7/spkg/build/sage-2.8.7 and type 'make'. Instead (using bash) type source local/bin/sage-env from the directory /home/wdj/sagefiles/sage-2.8.7 in order to set all environment variables correctly, then cd to /home/wdj/sagefiles/sage-2.8.7/spkg/build/sage-2.8.7 make[1]: *** [installed/sage-2.8.7] Error 1 make[1]: Leaving directory `/home/wdj/sagefiles/sage-2.8.7/spkg' real89m8.498s user48m0.352s sys 7m49.213s [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 ./sage -- | SAGE Version 2.8.7, Release Date: 2007-10-15 | | Type notebook() for the GUI, and license() for information.| -- --- type 'exceptions.ImportError' Traceback (most recent call last) /home/wdj/sagefiles/sage-2.8.7/local/bin/string in module() type 'exceptions.ImportError': No module named sage.misc.preparser_ipython WARNING: Failure executing code: 'import sage.misc.preparser_ipython; sage.misc.preparser_ipython.magma_colon_equals=True' --- type 'exceptions.ImportError' Traceback (most recent call last) /home/wdj/sagefiles/sage-2.8.7/local/bin/ipython console in module() type 'exceptions.ImportError': No module named sage.misc.misc ERROR: name 'sage_prompt' is not defined ERROR: name 'sage_prompt' is not defined [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 uname -a Linux tinah 2.6.16.13-4-default #1 Wed May 3 04:53:23 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 Cheers, Michael sage: An error occurred while installing flint-0.2.p4 Please email sage-develhttp://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/wdj/sagefiles/sage-2.8.7/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to
[sage-devel] Re: sage-2.8.7
On 10/16/07, mabshoff [EMAIL PROTECTED] wrote: On Oct 16, 5:46 pm, David Joyner [EMAIL PROTECTED] wrote: On 10/16/07, mabshoff [EMAIL PROTECTED] wrote: On Oct 16, 4:26 pm, David Joyner [EMAIL PROTECTED] wrote: Hi David, Hi David, This version does not upgrade or install on suse 9.1 amd64. As far as I can tell Suse 9.1 AMD64 ships with gcc 3.3, which is not C99 conform. So flint won't build, you need at least gcc 3.4 or higher. I would not make it a priority since these machines are due to be upgraded, but thought I'd let you know. However, it does not install on suse 10.2 either! Okay, but is seems that is unrelated to flint, because the error is caused by cython's pari glue code (see below) In case this helps: Could you please post the lets say 60-100 lines before that? I'm not sure if this is enough or not, but I hope it helps: SNIP that was plenty ;) running install running build running build_py running build_ext building 'sage.libs.pari.gen' extension gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/home/wdj/sagefiles/sage-2.8.7/local//include -I/home/wdj/sagefiles/sage-2.8.7/local//include/csage -I/home/wdj/sagefiles/sage-2.8.7/devel//sage/sage/ext -I/home/wdj/sagefiles/sage-2.8.7/local/include/python2.5 -c sage/libs/pari/gen.c -o build/temp.linux-x86_64-2.5/sage/libs/pari/gen.o -w sage/libs/pari/gen.c: In function '__pyx_f_py_3gen_3gen_factor': sage/libs/pari/gen.c:19784: internal compiler error: in merge_alias_info, at tree-ssa-copy.c:235 Please submit a full bug report, with preprocessed source if appropriate. gcc blows up, there is little we can do about that. Please check if there are updates compilers available for SuSE 10.2. If not you can either install your own gcc from sources or install the optional gcc.spkg. In that case you need to modify $LD_LIBRARY_PATH to also include $SAGE_LOCAL/lib64 before $SAGE_LOCAL/lib on an AMD 64 box. I will have a look at sage/libs/pari/gen.c:19784 and see if there is anything suspicious in that area. Could you please open a ticket along the lines of paru/gen.c causes internal compiler error on OpenSuSE 10.2 and give us uname -a and gcc -v. Done. http://sagetrac.org/sage_trac/ticket/908 This is on a work machine, so is not that easy to access, but I'll try to do some more testing. Cheers, Michael See URL:http://www.suse.de/feedback for instructions. error: command 'gcc' failed with exit status 1 sage: There was an error installing modified sage library code. real0m12.882s user0m8.653s sys 0m1.840s ERROR installing SAGE real10m8.202s user7m25.064s sys 0m12.473s sage: An error occurred while installing sage-2.8.7 Please email sage-develhttp://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/wdj/sagefiles/sage-2.8.7/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/wdj/sagefiles/sage-2.8.7/spkg/build/sage-2.8.7 and type 'make'. Instead (using bash) type source local/bin/sage-env from the directory /home/wdj/sagefiles/sage-2.8.7 in order to set all environment variables correctly, then cd to /home/wdj/sagefiles/sage-2.8.7/spkg/build/sage-2.8.7 make[1]: *** [installed/sage-2.8.7] Error 1 make[1]: Leaving directory `/home/wdj/sagefiles/sage-2.8.7/spkg' real89m8.498s user48m0.352s sys 7m49.213s [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 ./sage -- | SAGE Version 2.8.7, Release Date: 2007-10-15 | | Type notebook() for the GUI, and license() for information.| -- --- type 'exceptions.ImportError' Traceback (most recent call last) /home/wdj/sagefiles/sage-2.8.7/local/bin/string in module() type 'exceptions.ImportError': No module named sage.misc.preparser_ipython WARNING: Failure executing code: 'import sage.misc.preparser_ipython; sage.misc.preparser_ipython.magma_colon_equals=True' --- type 'exceptions.ImportError' Traceback (most recent call last) /home/wdj/sagefiles/sage-2.8.7/local/bin/ipython console in module() type 'exceptions.ImportError': No module named sage.misc.misc ERROR: name 'sage_prompt' is not defined ERROR: name 'sage_prompt' is not defined [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 uname -a Linux tinah 2.6.16.13-4-default #1 Wed May 3 04:53:23 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 Cheers, Michael sage: An error occurred while installing
[sage-devel] Re: sage-2.8.7
On Oct 16, 6:09 pm, David Joyner [EMAIL PROTECTED] wrote: On 10/16/07, mabshoff [EMAIL PROTECTED] wrote: Hi David, SNIP gcc blows up, there is little we can do about that. Please check if there are updates compilers available for SuSE 10.2. If not you can either install your own gcc from sources or install the optional gcc.spkg. In that case you need to modify $LD_LIBRARY_PATH to also include $SAGE_LOCAL/lib64 before $SAGE_LOCAL/lib on an AMD 64 box. I will have a look at sage/libs/pari/gen.c:19784 and see if there is anything suspicious in that area. Could you please open a ticket along the lines of paru/gen.c causes internal compiler error on OpenSuSE 10.2 and give us uname -a and gcc -v. Done.http://sagetrac.org/sage_trac/ticket/908 Some poking around reveals that this is a known regression with pari and gcc 4.1.0. See: http://gcc.gnu.org/ml/gcc-bugs/2006-04/msg00700.html http://lists.debian.org/debian-gcc/2006/05/msg00139.html This is on a work machine, so is not that easy to access, but I'll try to do some more testing. Well, could you just for fun rebuild pari? I think the compiler should blow up in that case, too, and I am curious why pari's build system doesn't catch it. Regarding a solution: I have discussed this with William before but I plan to offer a complete optional tool chain for compiling Sage that is integrated into the make system just for cases like this where the system's compiler screws us. The optional gcc spkg should work for you for now provided you fix $LD_LIBRARY_PATH in the way I mentioned earlier. If you do so first install the gcc spkg and then force a rebuild of pretty much every spkg with the exception of prereq I believe. The gcc compilers ends up in $SAGE_LOCAL, so there is no chance it could screw up your system or have side effects on other components. Cheers, Michael SNIP --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Another cython?
This must be a different cython, no? http://campbell.nu/oscar/cython/cython-doc.html Weird! JV --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unbelievably trivial
Hi Robert, I can't seem to get primessq to be defined as a cdef long*. I've tried cdef long primessq[46] = [...] cdef long *primessq = [...] etc. and they always give errors. Cython doesn't allow you to use macros (#define) I guess? JV --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Another cython?
On Oct 16, 7:23 pm, John Voight [EMAIL PROTECTED] wrote: This must be a different cython, no? http://campbell.nu/oscar/cython/cython-doc.html Weird! Definitely, but it is something completely different. It also seems dead, last update was at the end of 2000. JV Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Another cython?
Last update was over 7 years ago; 6 months after the creation date. I think it's safe to assume that this is a dead project. On Tue, 16 Oct 2007, John Voight wrote: This must be a different cython, no? http://campbell.nu/oscar/cython/cython-doc.html Weird! JV --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unbelievably trivial
On Oct 16, 2007, at 10:25 AM, John Voight wrote: Hi Robert, I can't seem to get primessq to be defined as a cdef long*. I've tried cdef long primessq[46] = [...] cdef long *primessq = [...] etc. and they always give errors. This is because [...] creates a python list, which is a PyObject* and can't be assigned to a long*. You would have to do something like cdef long primessq[46] py_primes = [...] for i from 0 = i 46: primessqi] = py_primes[i] # this does a python object - long conversion. Cython doesn't allow you to use macros (#define) I guess? You can define macros in a .h file, then cimport them, but you can't define macros directly in the cython file. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.7
Sage-2.8.5 compiled fine on SUSE, so this problem only occurs with a very recent version of gen.pyx. I recently modified the factor function in gen.pyx so that it would do provably-correct factorization of integers. Since that's the function causing the compiler error, probably something I did caused this. I'll likely make some attempts to modify my implementation to see if I can get around the broken compilers on SUSE. -- William On 10/16/07, mabshoff [EMAIL PROTECTED] wrote: On Oct 16, 6:09 pm, David Joyner [EMAIL PROTECTED] wrote: On 10/16/07, mabshoff [EMAIL PROTECTED] wrote: Hi David, SNIP gcc blows up, there is little we can do about that. Please check if there are updates compilers available for SuSE 10.2. If not you can either install your own gcc from sources or install the optional gcc.spkg. In that case you need to modify $LD_LIBRARY_PATH to also include $SAGE_LOCAL/lib64 before $SAGE_LOCAL/lib on an AMD 64 box. I will have a look at sage/libs/pari/gen.c:19784 and see if there is anything suspicious in that area. Could you please open a ticket along the lines of paru/gen.c causes internal compiler error on OpenSuSE 10.2 and give us uname -a and gcc -v. Done.http://sagetrac.org/sage_trac/ticket/908 Some poking around reveals that this is a known regression with pari and gcc 4.1.0. See: http://gcc.gnu.org/ml/gcc-bugs/2006-04/msg00700.html http://lists.debian.org/debian-gcc/2006/05/msg00139.html This is on a work machine, so is not that easy to access, but I'll try to do some more testing. Well, could you just for fun rebuild pari? I think the compiler should blow up in that case, too, and I am curious why pari's build system doesn't catch it. Regarding a solution: I have discussed this with William before but I plan to offer a complete optional tool chain for compiling Sage that is integrated into the make system just for cases like this where the system's compiler screws us. The optional gcc spkg should work for you for now provided you fix $LD_LIBRARY_PATH in the way I mentioned earlier. If you do so first install the gcc spkg and then force a rebuild of pretty much every spkg with the exception of prereq I believe. The gcc compilers ends up in $SAGE_LOCAL, so there is no chance it could screw up your system or have side effects on other components. Cheers, Michael SNIP -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: ode_solver
On Oct 14, 2007, at 1:40 AM, Joshua Kantor wrote: Good to see that you got things sped up. The factor of 30 or so slowdown is consistent with my experience comparing to matlab. I believe the issue is that due to the way the interface to gsl works explanation: The gsl ode solver is a c function that requires a C function pointer to be passed to it. So we have to convert the users python function into a C function, this is done by defining a cdef pyrex function that takes the users function as an argument and calls it. So in the end every function evaluation calls a C function which calls your python function. Python function calls are expensive so this adds overhead. It is possible to directly define the system as a pyrex object which makes the wrapping unnecessary and means all function calls are in C, this is much faster and I found it to be comparable to matlab, however, this is hard for a general user to do. Perhaps this could be written to use the new rdef function code, to make it easier for the user to provide a cdef function to the solver. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.7
On 10/16/07, mabshoff [EMAIL PROTECTED] wrote: On Oct 16, 6:09 pm, David Joyner [EMAIL PROTECTED] wrote: On 10/16/07, mabshoff [EMAIL PROTECTED] wrote: Hi David, SNIP gcc blows up, there is little we can do about that. Please check if there are updates compilers available for SuSE 10.2. If not you can either install your own gcc from sources or install the optional gcc.spkg. In that case you need to modify $LD_LIBRARY_PATH to also include $SAGE_LOCAL/lib64 before $SAGE_LOCAL/lib on an AMD 64 box. I will have a look at sage/libs/pari/gen.c:19784 and see if there is anything suspicious in that area. Could you please open a ticket along the lines of paru/gen.c causes internal compiler error on OpenSuSE 10.2 and give us uname -a and gcc -v. Done.http://sagetrac.org/sage_trac/ticket/908 Some poking around reveals that this is a known regression with pari and gcc 4.1.0. See: http://gcc.gnu.org/ml/gcc-bugs/2006-04/msg00700.html http://lists.debian.org/debian-gcc/2006/05/msg00139.html This is on a work machine, so is not that easy to access, but I'll try to do some more testing. Well, could you just for fun rebuild pari? I think the compiler should blow up in that case, too, and I am curious why pari's build system doesn't catch it. The command sage -f pari-2.3.2.p3 worked fine on the suse machine. Regarding a solution: I have discussed this with William before but I plan to offer a complete optional tool chain for compiling Sage that is integrated into the make system just for cases like this where the system's compiler screws us. The optional gcc spkg should work for you for now provided you fix $LD_LIBRARY_PATH in the way I mentioned earlier. If you do so first install the gcc spkg and then force a rebuild of pretty much every spkg with the exception of prereq I believe. The gcc compilers ends up in $SAGE_LOCAL, so there is no chance it could screw up your system or have side effects on other components. Cheers, Michael SNIP --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.7
On 10/16/07, David Joyner [EMAIL PROTECTED] wrote: On 10/16/07, mabshoff [EMAIL PROTECTED] wrote: -fPIC -I/home/wdj/sagefiles/sage-2.8.7/local//include -I/home/wdj/sagefiles/sage-2.8.7/local//include/csage -I/home/wdj/sagefiles/sage-2.8.7/devel//sage/sage/ext -I/home/wdj/sagefiles/sage-2.8.7/local/include/python2.5 -c sage/libs/pari/gen.c -o build/temp.linux-x86_64-2.5/sage/libs/pari/gen.o -w sage/libs/pari/gen.c: In function '__pyx_f_py_3gen_3gen_factor': sage/libs/pari/gen.c:19784: internal compiler error: in merge_alias_info, at tree-ssa-copy.c:235 Sage-2.8.5 compiled fine on SUSE, so this problem only occurs with a very recent version of gen.pyx. I recently modified the factor function in gen.pyx so that it would do provably-correct factorization of integers. Since that's the function causing the compiler error, probably something I did caused this. I'll likely make some attempts to modify my implementation to see if I can get around the broken compilers on SUSE... -- William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: ode_solver
Is rdef in sage 2.8.7? David On 10/16/07, Robert Bradshaw [EMAIL PROTECTED] wrote: On Oct 14, 2007, at 1:40 AM, Joshua Kantor wrote: Good to see that you got things sped up. The factor of 30 or so slowdown is consistent with my experience comparing to matlab. I believe the issue is that due to the way the interface to gsl works explanation: The gsl ode solver is a c function that requires a C function pointer to be passed to it. So we have to convert the users python function into a C function, this is done by defining a cdef pyrex function that takes the users function as an argument and calls it. So in the end every function evaluation calls a C function which calls your python function. Python function calls are expensive so this adds overhead. It is possible to directly define the system as a pyrex object which makes the wrapping unnecessary and means all function calls are in C, this is much faster and I found it to be comparable to matlab, however, this is hard for a general user to do. Perhaps this could be written to use the new rdef function code, to make it easier for the user to provide a cdef function to the solver. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: ode_solver
Yep, that was the main (in my opinion for SAGE) feature enhancement of cython 0.6.7 (included in sage 2.8.7). I am still not sold that rdef is the best name, been toying with bdef (for both) or something else, but we can start using it and if the signature changes, that's a one-line patch. - Robert On Oct 16, 2007, at 1:28 PM, David Roe wrote: Is rdef in sage 2.8.7? David On 10/16/07, Robert Bradshaw [EMAIL PROTECTED] wrote: On Oct 14, 2007, at 1:40 AM, Joshua Kantor wrote: Good to see that you got things sped up. The factor of 30 or so slowdown is consistent with my experience comparing to matlab. I believe the issue is that due to the way the interface to gsl works explanation: The gsl ode solver is a c function that requires a C function pointer to be passed to it. So we have to convert the users python function into a C function, this is done by defining a cdef pyrex function that takes the users function as an argument and calls it. So in the end every function evaluation calls a C function which calls your python function. Python function calls are expensive so this adds overhead. It is possible to directly define the system as a pyrex object which makes the wrapping unnecessary and means all function calls are in C, this is much faster and I found it to be comparable to matlab, however, this is hard for a general user to do. Perhaps this could be written to use the new rdef function code, to make it easier for the user to provide a cdef function to the solver. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Enhancing the SymbolicEquation class
I am currently adding a section on solving problems to the SAGE Programming For Newbies book and I would like to propose some enhancements to the SymbolicEquation class. The approach I am taking with the problem solving examples is to show how to use SAGE to solve a problem semi-manually and then how to solve it as automatically as possible (I have found that the semi-manual examples are often helpful for high school students who are required to learn traditional manual problem solving techniques). In the semi-manual example sections, I am finding that having an expand() method and a factor() method in the SymbolicEquation class would be helpful. It appears that these methods would simply need to call their counterparts in the SymbolicArithmetic objects that are assigned to the _left and _right instance variables. Also, I think it would be helpful to allow the SymbolicArithmetic objects that are assigned to the _left and _right instance variables to be made accessible individually. One reason for this is to allow them to be expanded or factored independently from each other. Thoughts? Ted --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Secure Notebook Deployment
Hello Professor Stein. For a final project at Case Western, I offered to setup a cluster of SAGE servers for the math department. Unfortunately, I found that the default server setup is highly insecure. I would like to collaborate with you and find a way to modify the notebook deployment to eliminate some basic (yet severe) security issues. Since I'm new to SAGE (and Python, for that matter), I decided that the easiest way to determine how to safely deploy a server would be to login to a public SAGE server and reverse-engineer its deployment based on my queries. Coincidentally, I stumbled upon your server (don't worry -- I did not execute any malicious commands.) and discovered several risks. Using the os module in Python, you can find the following: 1. All of the processes running on the server, as well as the parameters used to execute them. 2. The username, uid, groups, gid, etc of the current process. 3. The permissions of large portions of the file system. 4. The operating system the server is deployed on. 5. All of the users on the system. 6. The programs available to the users 7. Services running on the computer 8. Devices attached to the computer (I'm guessing this is a virtualized server, though...) These are just the things I can think of off the top of my head. This is more than enough information for a hacker to bring down the server. Here are just a few potential attacks I can think of: 1. scp appears to be among the available programs in what I'm guessing was an instance of the virtualized server image. Even if gcc was not available on the server side (it appears that it is), anyone could compile an executable on their own system and transfer it to the server via scp. 2. Delete any file owned by the server uid. Based on something I read on your forum, it appears that you used to be able to delete the SAGE server itself (this was the first exploit I checked for). 3. Kill processes owned by the server uid. This means you could: - Kill the server - Create a python script that ruins system resources by (1) creating random processes, and (2) killing these with signal 9. Signal 9 does not properly return resources to the OS, so looping this for a few minutes will just eat the system. 4. By combining (2) and (3), you can actually bring down the server in such a way that it will delete all of the user accounts (I tested this on my own server). Just do the following: import os; os.system(rm -Rf ~/.sage/*); # Destroy the contents of my .sage folder os.system(rm -Rf ../sage_notebook/*) # Destroy the cached notebook information os.system(ps -A | grep python); # Returns a list of python processes. Based # upon the information found in twistd.d, you # can easily guess which instance is hosting # your server ( It's the pid just before the one # given by twistd.pd ) os.system(kill -9 XXX) # Where XXX is the pid of the aforementioned python # interpreter. kill -9 ensures that no cleanup occurs # and the notebook is not saved back to disk. Hence, I can eliminate all user accounts and bring down the server. When the server is brought back up, all of the user account information will be gone. Given the current design, I believe this exploit is unavoidable (the server must have write permissions to those folders; hence, it can delete the files). Obviously, the biggest problem here is that the user has full access to a system terminal. A simple solution could be to re-bind the os.system function to None when the notebook is launched. Since I haven't dug deeply enough into the notebook code yet, I don't know if this is actually feasible (the notebook might use the os.system command. Furthermore, since I'm new to Python, there might be a way to unload and reload the module that I don't know about. This would eliminate the effect of the re-binding). Assuming that the re-binding trick works, we'd probably want to use the same trick to black-list other commands as well. Another alternative would be to allow the underlying operating system to have more control over the SAGE user accounts. Although SAGE allows individuals to login on the front page, all users are actually just the server user on the backend. In other words, this is really just an application-level user management scheme. In order to eliminate the 4th exploit I described, you would need to map these to system users. This would imply that: - The file deletions given above would only delete that user's files - The user would not have permission to bring down the server with a kill -9 You would
[sage-devel] Re: Secure Notebook Deployment
Hi, The public notebook servers on sage.math.washington.edu are jailed (http://sagemath.org/doc/html/inst/node10.html). Also there is a pool of 30 unix users that are used to evaluate worksheet code. That protects the main notebook system from a random user. Ulimit is also used. If I remember right William welcomes people to try to vandalize the notebook server at https://sage.math.washington.edu:8102 --- How William runs the public notebooks from William himself: (1) have a file that starts the notebook by running a .py file: [EMAIL PROTECTED]:~/nb1$ more start_notebook cd /home/server2/nb1 sage notebook.py nohup.out (2) The actual .py file: [EMAIL PROTECTED]:~/nb1$ more notebook.py from sage.all import * server_pool=['[EMAIL PROTECTED] -p 7000'%n for n in range(1,31)] notebook(port=8103, accounts=True, address='sage.math.washington.edu', secure=True, server_pool = server_pool, ulimit='-v 200') On 10/16/07, TrixB4Kidz [EMAIL PROTECTED] wrote: Hello Professor Stein. For a final project at Case Western, I offered to setup a cluster of SAGE servers for the math department. Unfortunately, I found that the default server setup is highly insecure. I would like to collaborate with you and find a way to modify the notebook deployment to eliminate some basic (yet severe) security issues. Since I'm new to SAGE (and Python, for that matter), I decided that the easiest way to determine how to safely deploy a server would be to login to a public SAGE server and reverse-engineer its deployment based on my queries. Coincidentally, I stumbled upon your server (don't worry -- I did not execute any malicious commands.) and discovered several risks. Using the os module in Python, you can find the following: 1. All of the processes running on the server, as well as the parameters used to execute them. 2. The username, uid, groups, gid, etc of the current process. 3. The permissions of large portions of the file system. 4. The operating system the server is deployed on. 5. All of the users on the system. 6. The programs available to the users 7. Services running on the computer 8. Devices attached to the computer (I'm guessing this is a virtualized server, though...) These are just the things I can think of off the top of my head. This is more than enough information for a hacker to bring down the server. Here are just a few potential attacks I can think of: 1. scp appears to be among the available programs in what I'm guessing was an instance of the virtualized server image. Even if gcc was not available on the server side (it appears that it is), anyone could compile an executable on their own system and transfer it to the server via scp. 2. Delete any file owned by the server uid. Based on something I read on your forum, it appears that you used to be able to delete the SAGE server itself (this was the first exploit I checked for). 3. Kill processes owned by the server uid. This means you could: - Kill the server - Create a python script that ruins system resources by (1) creating random processes, and (2) killing these with signal 9. Signal 9 does not properly return resources to the OS, so looping this for a few minutes will just eat the system. 4. By combining (2) and (3), you can actually bring down the server in such a way that it will delete all of the user accounts (I tested this on my own server). Just do the following: import os; os.system(rm -Rf ~/.sage/*); # Destroy the contents of my .sage folder os.system(rm -Rf ../sage_notebook/*) # Destroy the cached notebook information os.system(ps -A | grep python); # Returns a list of python processes. Based # upon the information found in twistd.d, you # can easily guess which instance is hosting # your server ( It's the pid just before the one # given by twistd.pd ) os.system(kill -9 XXX) # Where XXX is the pid of the aforementioned python # interpreter. kill -9 ensures that no cleanup occurs # and the notebook is not saved back to disk. Hence, I can eliminate all user accounts and bring down the server. When the server is brought back up, all of the user account information will be gone. Given the current design, I believe this exploit is unavoidable (the server must have write permissions to those folders; hence, it can delete the files). Obviously, the biggest problem here is that the user has full access to a system terminal. A simple solution could be to re-bind the os.system function to None when
[sage-devel] Re: Secure Notebook Deployment
On Oct 16, 2007, at 3:02 PM, Timothy Clemans wrote: Hi, The public notebook servers on sage.math.washington.edu are jailed (http://sagemath.org/doc/html/inst/node10.html). Also there is a pool of 30 unix users that are used to evaluate worksheet code. That protects the main notebook system from a random user. Ulimit is also used. If I remember right William welcomes people to try to vandalize the notebook server at https://sage.math.washington.edu:8102 I don't think vandalization is explicitly encouraged, however we would love to have feedback on how to make the current setup more secure. Making the python interpreter environment secure (e.g. disabling/remapping os.system) without crippling SAGE is probably an intractable problem, but running SAGE sessions with limited users with limited ulimit and permissions, and running the entire process in a jail, can serve to mitigate the problem. You are right in pointing out that the SAGE server is not completely secure, and it would be great if you could help us secure it further. - Robert --- How William runs the public notebooks from William himself: (1) have a file that starts the notebook by running a .py file: [EMAIL PROTECTED]:~/nb1$ more start_notebook cd /home/server2/nb1 sage notebook.py nohup.out (2) The actual .py file: [EMAIL PROTECTED]:~/nb1$ more notebook.py from sage.all import * server_pool=['[EMAIL PROTECTED] -p 7000'%n for n in range(1,31)] notebook(port=8103, accounts=True, address='sage.math.washington.edu', secure=True, server_pool = server_pool, ulimit='-v 200') On 10/16/07, TrixB4Kidz [EMAIL PROTECTED] wrote: Hello Professor Stein. For a final project at Case Western, I offered to setup a cluster of SAGE servers for the math department. Unfortunately, I found that the default server setup is highly insecure. I would like to collaborate with you and find a way to modify the notebook deployment to eliminate some basic (yet severe) security issues. Since I'm new to SAGE (and Python, for that matter), I decided that the easiest way to determine how to safely deploy a server would be to login to a public SAGE server and reverse-engineer its deployment based on my queries. Coincidentally, I stumbled upon your server (don't worry -- I did not execute any malicious commands.) and discovered several risks. Using the os module in Python, you can find the following: 1. All of the processes running on the server, as well as the parameters used to execute them. 2. The username, uid, groups, gid, etc of the current process. 3. The permissions of large portions of the file system. 4. The operating system the server is deployed on. 5. All of the users on the system. 6. The programs available to the users 7. Services running on the computer 8. Devices attached to the computer (I'm guessing this is a virtualized server, though...) These are just the things I can think of off the top of my head. This is more than enough information for a hacker to bring down the server. Here are just a few potential attacks I can think of: 1. scp appears to be among the available programs in what I'm guessing was an instance of the virtualized server image. Even if gcc was not available on the server side (it appears that it is), anyone could compile an executable on their own system and transfer it to the server via scp. 2. Delete any file owned by the server uid. Based on something I read on your forum, it appears that you used to be able to delete the SAGE server itself (this was the first exploit I checked for). 3. Kill processes owned by the server uid. This means you could: - Kill the server - Create a python script that ruins system resources by (1) creating random processes, and (2) killing these with signal 9. Signal 9 does not properly return resources to the OS, so looping this for a few minutes will just eat the system. 4. By combining (2) and (3), you can actually bring down the server in such a way that it will delete all of the user accounts (I tested this on my own server). Just do the following: import os; os.system(rm -Rf ~/.sage/*); # Destroy the contents of my .sage folder os.system(rm -Rf ../sage_notebook/*) # Destroy the cached notebook information os.system(ps -A | grep python); # Returns a list of python processes. Based # upon the information found in twistd.d, you # can easily guess which instance is hosting # your server ( It's the pid just before the one # given by twistd.pd ) os.system(kill -9 XXX) # Where XXX is the pid of the aforementioned python
[sage-devel] Re: Secure Notebook Deployment
On 10/16/07, Robert Bradshaw [EMAIL PROTECTED] wrote: The public notebook servers on sage.math.washington.edu are jailed (http://sagemath.org/doc/html/inst/node10.html). Also there is a pool of 30 unix users that are used to evaluate worksheet code. That protects the main notebook system from a random user. Ulimit is also used. If I remember right William welcomes people to try to vandalize the notebook server at https://sage.math.washington.edu:8102 No I don't! Basically, the situation with the public notebooks is that they will remain up as a sort of public service until somebody actually visibly vandalizes them, or uses them for nefarious purposes that are noticed and reported to me, at which time they will be taken down indefinitely. At that point I'll replace them by a closed notebook that only people I explicitly give accounts to will have access to. They have been open now for about 18 months -- it surprises me that I haven't had to switch to a closed system yet. I don't think vandalization is explicitly encouraged, however we would love to have feedback on how to make the current setup more secure. Making the python interpreter environment secure (e.g. disabling/remapping os.system) without crippling SAGE is probably an intractable problem, but running SAGE sessions with limited users with limited ulimit and permissions, and running the entire process in a jail, can serve to mitigate the problem. Which is exactly what we do. You are right in pointing out that the SAGE server is not completely secure, and it would be great if you could help us secure it further. Yes, I agree.I also agree that making the SAGE notebook server 100% secure while allowing arbitrary people to sign up for accounts with no accountability is a completely unsolvable problem. That said, ideas for making it more secure without making it impossibly hard to use, are always appreciated. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Secure Notebook Deployment
Hey again. I actually got a similar reply from William earlier today that I was going to append to this message (this post took quite some time to appear on google groups for whatever reason). The particular attack that I described is preventable, but the fact that the users have full access to a shell creates the potential for large security vulnerabilities. In particular, what about the other systems on your network? You've just given everyone access to your system behind your firewall. With this, I could easily write a script that punches a hole through your firewall and creates a pipe to one of your blocked ports. What I'm more concerned about is the fact that this model opens the rest of your network up. I mean, the attacker is behind the firewall on a computer that is part of a campus's internal network. One could build a crawler in Python that discovers the hidden network topology, port maps all of the systems, and sends the results back to their system via a raw socket or scp. So even if your server is rock-solid, the attacker has still learned about several other potential entry points into your network. Hence, the SAGE server could simply serve as a stepping stone into a larger-scale attack on the network. On Oct 16, 6:02 pm, Timothy Clemans [EMAIL PROTECTED] wrote: Hi, The public notebook servers on sage.math.washington.edu are jailed (http://sagemath.org/doc/html/inst/node10.html). Also there is a pool of 30 unix users that are used to evaluate worksheet code. That protects the main notebook system from a random user. Ulimit is also used. If I remember right William welcomes people to try to vandalize the notebook server athttps://sage.math.washington.edu:8102 --- How William runs the public notebooks from William himself: (1) have a file that starts the notebook by running a .py file: [EMAIL PROTECTED]:~/nb1$ more start_notebook cd /home/server2/nb1 sage notebook.py nohup.out (2) The actual .py file: [EMAIL PROTECTED]:~/nb1$ more notebook.py from sage.all import * server_pool=['[EMAIL PROTECTED] -p 7000'%n for n in range(1,31)] notebook(port=8103, accounts=True, address='sage.math.washington.edu', secure=True, server_pool = server_pool, ulimit='-v 200') On 10/16/07, TrixB4Kidz [EMAIL PROTECTED] wrote: Hello Professor Stein. For a final project at Case Western, I offered to setup a cluster of SAGE servers for the math department. Unfortunately, I found that the default server setup is highly insecure. I would like to collaborate with you and find a way to modify the notebook deployment to eliminate some basic (yet severe) security issues. Since I'm new to SAGE (and Python, for that matter), I decided that the easiest way to determine how to safely deploy a server would be to login to a public SAGE server and reverse-engineer its deployment based on my queries. Coincidentally, I stumbled upon your server (don't worry -- I did not execute any malicious commands.) and discovered several risks. Using the os module in Python, you can find the following: 1. All of the processes running on the server, as well as the parameters used to execute them. 2. The username, uid, groups, gid, etc of the current process. 3. The permissions of large portions of the file system. 4. The operating system the server is deployed on. 5. All of the users on the system. 6. The programs available to the users 7. Services running on the computer 8. Devices attached to the computer (I'm guessing this is a virtualized server, though...) These are just the things I can think of off the top of my head. This is more than enough information for a hacker to bring down the server. Here are just a few potential attacks I can think of: 1. scp appears to be among the available programs in what I'm guessing was an instance of the virtualized server image. Even if gcc was not available on the server side (it appears that it is), anyone could compile an executable on their own system and transfer it to the server via scp. 2. Delete any file owned by the server uid. Based on something I read on your forum, it appears that you used to be able to delete the SAGE server itself (this was the first exploit I checked for). 3. Kill processes owned by the server uid. This means you could: - Kill the server - Create a python script that ruins system resources by (1) creating random processes, and (2) killing these with signal 9. Signal 9 does not properly return resources to the OS, so looping this for a few minutes will just eat the system. 4. By combining (2) and (3), you can actually bring down the server in such a way that it will delete all of the user accounts (I tested this on my own server). Just do the following: import os; os.system(rm -Rf ~/.sage/*); # Destroy the contents of my .sage folder os.system(rm -Rf
[sage-devel] Re: Secure Notebook Deployment
On 10/16/07, Timothy Clemans [EMAIL PROTECTED] wrote: William do you really think the notebooks can be vandalized? Yes. The only secure computer is one that is not connected to the internet and is behind a secure wall with armed guards, etc. It helps if the computer is broken too. Security for machines offering services online is just a matter of degrees. If I remember right William welcomes people to try to vandalize the notebook server at https://sage.math.washington.edu:8102 No I don't! The e-mail below is what I thinking of. touché You're right. But seriously, I didn't mean that people should try to vandalize that one forever. Thanks for forwarding my email. William -- Forwarded message -- From: William Stein [EMAIL PROTECTED] Date: Jun 27, 2007 12:39 AM Subject: [sage-devel] Re: SAGE notebook 2 To: sage-devel@googlegroups.com Hi, SUMMARY: I've made the public SAGE notebook servers nontrivial to seriously vandalize or kill... I hope. Try to crack them (especially https://sage.math.washington.edu:8102). DETAILS: For the first time in history I've finally setup a first not totally-insanely-trivial-to-vandalize server in the chroot jail on sage.math. In fact all three servers: https://sage.math.washington.edu:8100 https://sage.math.washington.edu:8101 https://sage.math.washington.edu:8102 --- please hack me. are so configured. What happens is that each user worksheet runs as a separate user from the notebook server itself. In fact, there is a rotating pool of 30 worksheet users. It should now be *extremely* difficult for a user of the notebook to kill the notebook process itself, or delete vital user data. So, for the first time ever, I invite you to please try to see if you can kill the notebook server. Let's restrict the attacks to the one on port 8102. See if you break it by running malicious commands in a worksheet. NOTE: It is, of course, trivial to denial-of-service sage.math by just running lots and lots of processes at once. Please don't do that. William On 10/16/07, William Stein [EMAIL PROTECTED] wrote: On 10/16/07, Robert Bradshaw [EMAIL PROTECTED] wrote: The public notebook servers on sage.math.washington.edu are jailed (http://sagemath.org/doc/html/inst/node10.html). Also there is a pool of 30 unix users that are used to evaluate worksheet code. That protects the main notebook system from a random user. Ulimit is also used. If I remember right William welcomes people to try to vandalize the notebook server at https://sage.math.washington.edu:8102 No I don't! Basically, the situation with the public notebooks is that they will remain up as a sort of public service until somebody actually visibly vandalizes them, or uses them for nefarious purposes that are noticed and reported to me, at which time they will be taken down indefinitely. At that point I'll replace them by a closed notebook that only people I explicitly give accounts to will have access to. They have been open now for about 18 months -- it surprises me that I haven't had to switch to a closed system yet. I don't think vandalization is explicitly encouraged, however we would love to have feedback on how to make the current setup more secure. Making the python interpreter environment secure (e.g. disabling/remapping os.system) without crippling SAGE is probably an intractable problem, but running SAGE sessions with limited users with limited ulimit and permissions, and running the entire process in a jail, can serve to mitigate the problem. Which is exactly what we do. You are right in pointing out that the SAGE server is not completely secure, and it would be great if you could help us secure it further. Yes, I agree.I also agree that making the SAGE notebook server 100% secure while allowing arbitrary people to sign up for accounts with no accountability is a completely unsolvable problem. That said, ideas for making it more secure without making it impossibly hard to use, are always appreciated. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~--- -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and
[sage-devel] Re: Secure Notebook Deployment
I don't think it is the main jails you would block since they have to receive and send data in order for the public to access them. Maybe you would block the pool of sage__ users from accessing the net using Iptables. (this might be helpful -- http://www.thescripts.com/forum/thread705507.html) Also maybe you could have a whitelist for the sloane database and the others. On 10/16/07, William Stein [EMAIL PROTECTED] wrote: On 10/16/07, TrixB4Kidz [EMAIL PROTECTED] wrote: Hey again. I actually got a similar reply from William earlier today that I was going to append to this message (this post took quite some time to appear on google groups for whatever reason). The particular attack that I described is preventable, but the fact that the users have full access to a shell creates the potential for large security vulnerabilities. In particular, what about the other systems on your network? You've just given everyone access to your system behind your firewall. With this, I could easily write a script that punches a hole through your firewall and creates a pipe to one of your blocked ports. The sage server isn't behind any firewall. The math department does have a firewall, but sage is in front of it rather than behind it. That said, there are some services accessible form the server that are only campus-accessible, e.g., library web servers. What I'm more concerned about is the fact that this model opens the rest of your network up. I mean, the attacker is behind the firewall on a computer that is part of a campus's internal network. One could build a crawler in Python that discovers the hidden network topology, port maps all of the systems, and sends the results back to their system via a raw socket or scp. So even if your server is rock-solid, the attacker has still learned about several other potential entry points into your network. Hence, the SAGE server could simply serve as a stepping stone into a larger-scale attack on the network. It would be helpful if I blocked all outgoing connection from the notebook's chroot jail. I actually have planned to do so for a while, but haven't got around to it. An number of things would be more frustrating with this model, e.g., users couldn't use any of the network-aware databases that Sage has, or pull up files in the notebook from elsewhere online. But that's perhaps not an unreasonable inconvenience for added security. Actually, how do I setup networking in the chroot jail so processes in the chroot can't create outgoing connections, but processes not in the chroot can? -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Secure Notebook Deployment
On 10/16/07, Timothy Clemans [EMAIL PROTECTED] wrote: I don't think it is the main jails you would block since they have to receive and send data in order for the public to access them. Maybe you would block the pool of sage__ users from accessing the net using Iptables. (this might be helpful -- http://www.thescripts.com/forum/thread705507.html) Also maybe you could have a whitelist for the sloane database and the others. You're right; that's exactly what I want to do. I want to make it so the working pool sage* users can't use the network in any way. They are users in the chroot jail, so the question is -- how can I make it so a given user can't use the internet on a unix machine, assuming said user doesn't hack the machine and become a different user? And yes, I know, if only I would release a SageLite that was the sage notebook without the hard-to-build Sage math library, then all kinds of unix gurus would just solve all these problems for me (since then the notebook would be popular and independently interesting beyond Sage). I really want to do that. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Secure Notebook Deployment
On Oct 17, 1:09 am, William Stein [EMAIL PROTECTED] wrote: On 10/16/07, Timothy Clemans [EMAIL PROTECTED] wrote: I don't think it is the main jails you would block since they have to receive and send data in order for the public to access them. Maybe you would block the pool of sage__ users from accessing the net using Iptables. (this might be helpful -- http://www.thescripts.com/forum/thread705507.html) Also maybe you could have a whitelist for the sloane database and the others. You're right; that's exactly what I want to do. I want to make it so the working pool sage* users can't use the network in any way. They are users in the chroot jail, so the question is -- how can I make it so a given user can't use the internet on a unix machine, assuming said user doesn't hack the machine and become a different user? I would suggest not to actually use unixy infrastructure to create the users. But that certainly involves a decent amount of coding to do your own user creation/permission management and so on. Trying to secure unix user accounts seems doomed in my opinion. Using IP tables is also pointless because you have http[s] access and can bring in everything you need that way. It is just a little bit more effort. And yes, I know, if only I would release a SageLite that was the sage notebook without the hard-to-build Sage math library, then all kinds of unix gurus would just solve all these problems for me (since then the notebook would be popular and independently interesting beyond Sage). I really want to do that. I agree. William Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Secure Notebook Deployment
I would suggest not to actually use unixy infrastructure to create the users. But that certainly involves a decent amount of coding to do your own user creation/permission management and so on. Trying to secure unix user accounts seems doomed in my opinion. I agree to some extent. However, Python and sh are really only limited by the permissions of the underlying Unix user. If this user can execute processes / open sockets / etc, then the notebook is still at risk of becoming a unit of a larger attack. sh can be limited by creating a small enough jail for the server-side users. Is it possible to create a white-list (or possibly black-list) of Python bindings? This could be used to offer only a subset of the typical Python commands. The problem I can see with this solution is that certain core SAGE functions might require these hidden functions (ex: functions that need to access databases). Using the bindings in the SAGE core and then unbinding them is probably not a strong enough solution. Based upon what I know about Python binding (which isn't much), it sounds like it is impossible to instantiate pure private variables; hence, a determined user could always find an object that is using the blocked functionality and bind to one of its private variables. An alternative would be to completely eliminate the bindings from the core and instead encapsulate the necessary functionality within another language, such as C, C++, or Java. In this case, sockets would still be usable by the core libraries, but they would not be available within the shells. -- TrixB4Kidz --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Secure Notebook Deployment
And yes, I know, if only I would release a SageLite that was the sage notebook without the hard-to-build Sage math library, then all kinds of unix gurus would just solve all these problems for me (since then the notebook would be popular and independently interesting beyond Sage). I really want to do that. Yes please. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: random polynomial generation
2007/10/16, Steffen [EMAIL PROTECTED]: Hi didier, the implementation does not return a polynomial of a total degree of at most 4, but a polynomial of total degree of at most 4/2 = 2 in x and in y. If I change the total degree to 5, nothing happens, since 5/2 = 2. This might be a bug in the implementation. However I am happy with this behaviour and maybe there should be the option for choosing the total degree or the degree in every variable. For total degree, I'm using the definition here: http://planetmath.org/encyclopedia/OrderAndDegreeOfPolynomial.html So I am not concerned about individual degrees at all. Furthermore I am not happy with this implementation in general. In step 1.) you do not care about repetitions. This sounds reasonible since repetitions are part of randomness. Later in step 3) you do care about repetetions and summarise them under the value 0. If the value 0 I don't explicitly discard repetitions in 3), the dictionary object takes care of that by discarding repeated keys (in this case, the keys are the degree tuples). didier gains the same importance as all other values in the corresponding set of values, than the multiple occurance of 0 is a repetition, too. I am quite new in SAGE and have no idea how sage code looks like, but I will have a look and see if I can do some changes :-) Cheers, Steffen --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: random polynomial generation
On Oct 16, 8:32 pm, didier deshommes [EMAIL PROTECTED] wrote: 2007/10/16, Steffen [EMAIL PROTECTED]: Hi didier, the implementation does not return a polynomial of a total degree of at most 4, but a polynomial of total degree of at most 4/2 = 2 in x and in y. If I change the total degree to 5, nothing happens, since 5/2 = 2. This might be a bug in the implementation. However I am happy with this behaviour and maybe there should be the option for choosing the total degree or the degree in every variable. For total degree, I'm using the definition here:http://planetmath.org/encyclopedia/OrderAndDegreeOfPolynomial.html So I am not concerned about individual degrees at all. Given this definition (which I agree is correct), I would expect that if I ask for a total degree of 4, I would sometimes see monomials like x^4 or x*y^3. I think the lack of these monomials is what surprises (and, coincidentally, pleases) Steffen. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
