Re: Boost compilation problem
Zitat von Derek Atkins : This works well because generally code that targets an older version of a dependency will usually still work when compiled against a newer version of that dependency. So if we target version 1.48 of libFoo it will generally still work with version 1.50 of libFoo that another user has. Doing it this way makes it easy for users to build gnucash; they don't have to figure out how to install "newer" dependencies on their systems. That's the correct explanation of the thought process of how we chose boost-1.48 as target. However, I see two issues here: Firstly, as Aaron figured out, newer distros (with newer gcc's which have newer warnings) won't even build with the old target boost anymore. Secondly, I think we're overrating the fact that *users* might want to *compile* gnucash for themselves and need to have it easy to do so. I mean, this small minority of people who compile gnucash from source can also be asked to compile boost from source. IMHO there's almost no difference between the set of people who can compile gnucash from source, and those who can compile both boost and gnucash from source. I think we should still take the distro issue into consideration, but can decide on a compromise between our developers' convenience (it's us who do the work, anyway) and the dependency restrictions. In case of boost, IMHO as Aaron told us, 1.48 doesn't even compile anymore with current gcc and is therefore a nuisance to be used by us developers. We should lift this up to some newer version, such as 1.52 or 1.56, whatever will be out on the market for 6-12 months at the targeted stable release date. But I think any extra effort to get boost-1.48 compile with our up-to-date build systems is rather wasted and should better be invested somewhere else. Boost-1.52 plus/minus one is my proposal. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Security implications of loading custom reports
John Ralls writes: > On Oct 23, 2014, at 9:25 AM, Derek Atkins wrote: > >> John Ralls writes: >> I'm not sure this is possible in guile only. A report is written as a guile module. Loading the module already executes code (gnc:define-report). That code can be abused do bad things when loading a custom report. >>> >>> Wow. That’s an incredible failure for something that’s promoted as an >>> application scripting language. >> >> I'm not sure that people care about security when you're modifying your >> own application. Similarly, emacs' e-lisp lets you get into pretty much >> any part of the application. That's not considered a failure, either. >> It's a feature. >> >> We could limit the "damage" by limiting which APIs are available. But >> it's a turing-complete language so you could do anything. >> >> I just don't see the reason to rework all this. What's the threat >> you're trying to prevent (other than "broken report crashes the app -- >> which we should fix by catching the exception). >> > > The threat is someone malicious installing a script either by phishing > the user or by gaining access to the user’s machine. Such a malicious > script wouldn’t be limited to crashing GnuCash: It can do anything any > program can do. If someone breaks into your system in order to install a script they could do much worse than installing some bogus scheme in gnucash. I just don't see this threat has serious. It's more likely someone would install a browser plugin to upload all key-presses. > Yes, I agree that emacs has even more vulnerability, but we’re not > responsible for emacs. In some ways it’s a feature for emacs, but it’s > also the reason behind the snarky “emacs isn’t an editor, it’s a way > of life”. Unlike emacs, GnuCash doesn’t aspire to be an all-in-one > desktop and development environment. > > Regards, > John Ralls -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Boost compilation problem
Christian Stimming writes: > Zitat von Derek Atkins : >> This works well because generally code that targets an older version of >> a dependency will usually still work when compiled against a newer >> version of that dependency. So if we target version 1.48 of libFoo it >> will generally still work with version 1.50 of libFoo that another user >> has. >> >> Doing it this way makes it easy for users to build gnucash; they don't >> have to figure out how to install "newer" dependencies on their systems. > > That's the correct explanation of the thought process of how we chose > boost-1.48 as target. However, I see two issues here: Firstly, as > Aaron figured out, newer distros (with newer gcc's which have newer > warnings) won't even build with the old target boost anymore. > Secondly, I think we're overrating the fact that *users* might want to > *compile* gnucash for themselves and need to have it easy to do so. I > mean, this small minority of people who compile gnucash from source > can also be asked to compile boost from source. IMHO there's almost no > difference between the set of people who can compile gnucash from > source, and those who can compile both boost and gnucash from source. We can look at the SF pages and see that the 2.6.4 sources have been downloaded about 500 times per week! So I suspect that people are definitely downloading the sources frequently, looks like 30-65 times per day over the past week. As for compiling boost from source, the question isn't whether they can, but whether they can make it co-exist with the distributions' version. > I think we should still take the distro issue into consideration, but > can decide on a compromise between our developers' convenience (it's > us who do the work, anyway) and the dependency restrictions. In case > of boost, IMHO as Aaron told us, 1.48 doesn't even compile anymore > with current gcc and is therefore a nuisance to be used by us > developers. You're assuming that I meant we should build 1.48 on current systems, which is not what I'm suggesting. We could (and probably should) just perform the testing against minimum version on the target platforms (arguably in a VM or chroot). Honestly, just having some build slaves would solve this problem. > We should lift this up to some newer version, such as 1.52 > or 1.56, whatever will be out on the market for 6-12 months at the > targeted stable release date. But I think any extra effort to get > boost-1.48 compile with our up-to-date build systems is rather wasted > and should better be invested somewhere else. Boost-1.52 plus/minus > one is my proposal. Yes, I agree. But right now the only choice I see is whether to keep at Debian stable or move to Debian testing (which does get us a small boost in boost) :) > Regards, > > Christian -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Security implications of loading custom reports
> On Oct 24, 2014, at 7:29 AM, Derek Atkins wrote: > > John Ralls writes: > >> On Oct 23, 2014, at 9:25 AM, Derek Atkins wrote: >> >>> John Ralls writes: >>> > I'm not sure this is possible in guile only. A report is written as > a guile module. Loading the module already executes code > (gnc:define-report). That code can be abused do bad things when > loading a custom report. Wow. That’s an incredible failure for something that’s promoted as an application scripting language. >>> >>> I'm not sure that people care about security when you're modifying your >>> own application. Similarly, emacs' e-lisp lets you get into pretty much >>> any part of the application. That's not considered a failure, either. >>> It's a feature. >>> >>> We could limit the "damage" by limiting which APIs are available. But >>> it's a turing-complete language so you could do anything. >>> >>> I just don't see the reason to rework all this. What's the threat >>> you're trying to prevent (other than "broken report crashes the app -- >>> which we should fix by catching the exception). >>> >> >> The threat is someone malicious installing a script either by phishing >> the user or by gaining access to the user’s machine. Such a malicious >> script wouldn’t be limited to crashing GnuCash: It can do anything any >> program can do. > > If someone breaks into your system in order to install a script they > could do much worse than installing some bogus scheme in gnucash. I > just don't see this threat has serious. It's more likely someone would > install a browser plugin to upload all key-presses. No one need break into your system. Simply promoting a "cool report" for download on the user list would be sufficient. Roger, there are broader attacks possible, but most of the obvious targets like browsers are making it harder, so the bad guys will be looking for less obvious targets. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Boost compilation problem
On Fri, Oct 24, 2014 at 11:10 AM, Derek Atkins wrote: > > As for compiling boost from source, the question isn't whether they can, > but whether they can make it co-exist with the distributions' version. > > Just to be clear, if I'm understanding correctly, this is done by building boost with ./bootstrap --prefix=/home/derek/boostbuild; , and when building gnucash, ./configure --with-booth=/home/derek/boostbuild; I hope that clears up that point sufficiently. In Christ, Aaron ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Boost compilation problem
> On Oct 24, 2014, at 8:10 AM, Derek Atkins wrote: > > Christian Stimming writes: > >> Zitat von Derek Atkins : >>> This works well because generally code that targets an older version of >>> a dependency will usually still work when compiled against a newer >>> version of that dependency. So if we target version 1.48 of libFoo it >>> will generally still work with version 1.50 of libFoo that another user >>> has. >>> >>> Doing it this way makes it easy for users to build gnucash; they don't >>> have to figure out how to install "newer" dependencies on their systems. >> >> That's the correct explanation of the thought process of how we chose >> boost-1.48 as target. However, I see two issues here: Firstly, as >> Aaron figured out, newer distros (with newer gcc's which have newer >> warnings) won't even build with the old target boost anymore. >> Secondly, I think we're overrating the fact that *users* might want to >> *compile* gnucash for themselves and need to have it easy to do so. I >> mean, this small minority of people who compile gnucash from source >> can also be asked to compile boost from source. IMHO there's almost no >> difference between the set of people who can compile gnucash from >> source, and those who can compile both boost and gnucash from source. > > We can look at the SF pages and see that the 2.6.4 sources have been > downloaded about 500 times per week! So I suspect that people are > definitely downloading the sources frequently, looks like 30-65 times > per day over the past week. > > As for compiling boost from source, the question isn't whether they can, > but whether they can make it co-exist with the distributions' version. > >> I think we should still take the distro issue into consideration, but >> can decide on a compromise between our developers' convenience (it's >> us who do the work, anyway) and the dependency restrictions. In case >> of boost, IMHO as Aaron told us, 1.48 doesn't even compile anymore >> with current gcc and is therefore a nuisance to be used by us >> developers. > > You're assuming that I meant we should build 1.48 on current systems, > which is not what I'm suggesting. We could (and probably should) just > perform the testing against minimum version on the target platforms > (arguably in a VM or chroot). First off, Debian Stable is at Boost 1.49, not 1.48, and Gnucash master built just fine on it yesterday. > > Honestly, just having some build slaves would solve this problem. > >> We should lift this up to some newer version, such as 1.52 >> or 1.56, whatever will be out on the market for 6-12 months at the >> targeted stable release date. But I think any extra effort to get >> boost-1.48 compile with our up-to-date build systems is rather wasted >> and should better be invested somewhere else. Boost-1.52 plus/minus >> one is my proposal. > > Yes, I agree. But right now the only choice I see is whether to keep at > Debian stable or move to Debian testing (which does get us a small boost > in boost) :) Actually it gives a big boost: To 1.55. F20 and OpenSuSE are on 1.54, Gentoo has 1.56 (current). I'm inclined to set it to 1.49 for now and 1.54 when we get around to needing some of the newer libraries. Depending on what gets added or improved in the next 2 years we may want to raise it again before we start the 2.7 testing cycle. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Boost compilation problem
Nice one Derek :-) Sorry Aaron, while I don't have a problem with you believing something different to me, it is annoying to be subjected to your personal beliefs on every email from you. Regards, Chris Good > On 25 Oct 2014, at 3:00 am, gnucash-devel-requ...@gnucash.org wrote: > > Send gnucash-devel mailing list submissions to >> ! >> >> In Christ, >> Aaron Laws > > In Moses, > >> gnucash-devel mailing list >> gnucash-devel@gnucash.org >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
