Re: [gentoo-dev] RFC: Bugzilla arch list reordering

[Dirkjan Ochtman]

On Mon, Jan 15, 2018 at 11:01 PM, Michał Górny  wrote:

> Besides regrouping, I've also reordered the keywords to use the same
> sorting order as eshowkw (i.e. ppc before ppc64), moved 'BSD' into teams

(in contrast to 'AMD64 FBSD' and 'X86 FBSD'), and added 'Prefix' team.
>

I think these are all good improvements. In terms of having the best user
experience, I would actually advocate changing the order to sort by
frequency/use. So the list would just start with amd64, then x86, arm64,
ppc, or something like that? Probably we should still match order with
eshowkw, maybe there should be a file somewhere that keeps the current
order and we can regenerate it from time to time based on the latest use
counts.

Regards,

Dirkjan

Re: [gentoo-dev] RFC: Bugzilla arch list reordering

[Michał Górny]

W dniu wto, 16.01.2018 o godzinie 10∶15 +0100, użytkownik Dirkjan
Ochtman napisał:
> On Mon, Jan 15, 2018 at 11:01 PM, Michał Górny  wrote:
> 
> > Besides regrouping, I've also reordered the keywords to use the same
> > sorting order as eshowkw (i.e. ppc before ppc64), moved 'BSD' into teams
> 
> (in contrast to 'AMD64 FBSD' and 'X86 FBSD'), and added 'Prefix' team.
> > 
> 
> I think these are all good improvements. In terms of having the best user
> experience, I would actually advocate changing the order to sort by
> frequency/use. So the list would just start with amd64, then x86, arm64,
> ppc, or something like that? Probably we should still match order with
> eshowkw, maybe there should be a file somewhere that keeps the current
> order and we can regenerate it from time to time based on the latest use
> counts.
> 

I disagree. I think most of the developers are used to the lexical sort,
and it keeps the order predictable. While I suppose keeping amd64
and x86 alongside for the sake of being commonly used would make sense,
I really have no clue how that would affect other arches.

By 'frequency' did you mean how many ebuilds are having the specific
keyword? Could you make some quick stats that would show how this would
look like right now?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to ${PYTHON_COMPAT_OVERRIDE}

[Francesco Riosa]

On 16/01/2018 08:57, Michał Górny wrote:
> W dniu pon, 15.01.2018 o godzinie 16∶27 +0100, użytkownik Francesco
> Riosa napisał:
>> In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized and added
>> to all python eclasses, it's useful for developers that want test and
>> mark the package for newer versions of python.
>>
>> However (unless I'm missing something) PYTHON_COMPAT_OVERRIDE is not
>> usable if:
>> - the user want only python 2.7 and 3.6 (latest) installed
>>   no python 3.5
>> - don't want to mess dependencies (the warnings in the eclass are scary)
> Because it is not meant to be used for that purpose, and it is not meant
> to be used by users at all! It's just a quick hack for developer who
> wants to UNLIKELY(check if package works with implementation X) before
> he starts the effort on modifying PYTHON_COMPAT in ebuilds.
supposed that, but at this point I fail to see the benefit versus the
added complexity in the eclasses, however that's not my business.
>
>> So, what can be done to let the user choose it's preferred python
>> version(s) without having to build it's own overlay?
>>
>> One solution is to change ebuilds in tree to include a user variable in
>> the PYTHON* arrays, example:
>>
>> -PYTHON_COMPAT=( python3_{4,5} )
>> +PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} )
>>
>> if someone want to bet that packages are ok with 3.6/latest (even before
>> a developer tested it) then add PYTHON_COMPAT_ADD=python3_6 to
>> /etc/portage/make.conf and run egencache.
>>
>> Indeed biggest problem in changing $PYTHON* variables is that metadata
>> also change and cache is invalidated.
>>
>> However if the problem is known (*), and if the change to metadata is
>> stable per "system"/"gentoo repo clone", then the solution to the
>> problem is easy; just run $(egencache --update -j$(nproc) --repo gentoo)
>> after each sync.
> This won't work. You are wrongly presuming that egencache regenerates
> cache unconditionally. It does so only if either ebuild or eclass
> content changed. So it worked for you once because you modified ebuilds
> and/or eclasses. It won't work when you change PYTHON_COMPAT_ADD.
>
> I haven't checked the Portage details but it may see the metadata change
> when installing the package. Which means it would install package with
> unsatisfied dependencies (because it satisfied dependencies from cache),
> then store the final dependencies and TADAAM, you've got broken
> depgraph.
ouch, that basically kill the proposal, unless portage is modified to
check known cache modifying variables, which isn't something I'd like to
create.
>
>> The most important thing is that this solution is scriptable and need no
>> human intervention.
> So is gpy-upgrade-impl.
It seem to do the job, one piece missing is something that monitor
gentoo repository to see if it has better version (still w/o wanted
python), an inotify for ebuilds. Suggestions?
>
>> Notice also that it's easy to have an array with duplicate values
>> PYTHON_COMPAT=( python3_6 python3_6 ) but at a first glance
>> _python_set_impls() is resilient to this.
>>
>> (*) In a perfect world, where global variables that can change metadata
>> are known {egencache,emerge} can be made conscious and warn if the cache
>> is invalid, but that's out of scope at the moment.
> This isn't perfect world. This is the exact opposite of it, it would be
> a mess. Also, conscious tools would probably start plotting against you
> if you'd give them such horrible tasks.
>

Re: [gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to ${PYTHON_COMPAT_OVERRIDE}

[Francesco Riosa]

On 16/01/2018 01:40, Alec Warner wrote:
>
>
> On Mon, Jan 15, 2018 at 7:05 PM, Francesco Riosa  > wrote:
>
>
>
> On 15/01/2018 18:07, Mike Gilbert wrote:
> > On Mon, Jan 15, 2018 at 10:27 AM, Francesco Riosa
> mailto:viv...@gmail.com>> wrote:
> >> In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized
> and added
> >> to all python eclasses, it's useful for developers that want
> test and
> >> mark the package for newer versions of python.
> >>
> >> However (unless I'm missing something) PYTHON_COMPAT_OVERRIDE
> is not
> >> usable if:
> >> - the user want only python 2.7 and 3.6 (latest) installed
> >>   no python 3.5
> >> - don't want to mess dependencies (the warnings in the eclass
> are scary)
> >>
> >> So, what can be done to let the user choose it's preferred python
> >> version(s) without having to build it's own overlay?
> >>
> >> One solution is to change ebuilds in tree to include a user
> variable in
> >> the PYTHON* arrays, example:
> >>
> >> -PYTHON_COMPAT=( python3_{4,5} )
> >> +PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} )
> >>
> >> if someone want to bet that packages are ok with 3.6/latest
> (even before
> >> a developer tested it) then add PYTHON_COMPAT_ADD=python3_6 to
> >> /etc/portage/make.conf and run egencache.
> > I like the idea to inject values into PYTHON_COMPAT instead of
> > overriding it completely. I'm pretty sure this can/should be
> > implemented in the eclass without touching ebuilds.
> In my mind that was to leave ebuilds developers the ability to opt
> out,
> but well that could also be done in the eclasses.
> Opt out could be beneficial for packages that only support python 2.7,
> or where there are known and documented problems with different python
> versions.
> >
> > I'm not sure I really like the idea of affecting the other metadata
> > variables. I can see your point about wanting to remove python
> > versions that would otherwise satisfy dependencies. If metadata is
> > modified this way, it would definitely be "unsupported".
> I've not tought about remove python versions, only add them
> (beneficial
> for users that like to use experimental python versions)
> However the supported python version are translated and build
> important
> cached variables IUSE, DEPEND, etc. so there is no way to cleanly
> modify
> those variable after the cache has been generated.
> The only viable option is to regenerate, update or delete it.
>
> >
> > As far as implementation, you would probably need to write the
> patches for this.
> If there is consensus that's not a problem, cannot guarantee to be
> fast
> however
> >
> > Also, I expect the QA team might have some objections, so you
> may want
> > to discuss it with them (especially mgorny) before spending too much
> > time on it.
> I'd like to hear mgorny opinions but that should be a more extended
> decision than only QA and the python eclasses developer(s).
> If nothing else because deciding that sometimes may be good to let the
> user break the cache is a global decision and documentation need to be
> added.
>
>
> I'm seeing less value in this being a 'cache-breaking' exercise and
> more value in it simply being a custom eclass.
>
> If you hoist the eclass into an overlay and modify it (e.g. to set the
> var and get the deps you want) the caching
> all works out fine.
>
> 1. The source of the data is the hoisted eclass.
> 2. The eclass mtime changed.
> 3. package managers can see that and update cache metadata for
> inheriting ebuilds.
> 4. Bonus, once the cache is generated we have a valid means to see if
> the cache remains valid.
> 5. Double bonus, any ebuilds not inheriting the eclass are unaffected.
>
> I'm not sure why this is so onerous.
>
> -A
That's a good idea, in the past I've failed to completely understand how
portage inherit eclasses in overlays, but if I can figure that out
probably this could be a solution.
Also depending from the magnitude of changes the four python eclasses
need and the correlated maintenance burden.

Re: [gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to ${PYTHON_COMPAT_OVERRIDE}

[Michał Górny]

W dniu wto, 16.01.2018 o godzinie 14∶09 +0100, użytkownik Francesco
Riosa napisał:
> 
> On 16/01/2018 08:57, Michał Górny wrote:
> > W dniu pon, 15.01.2018 o godzinie 16∶27 +0100, użytkownik Francesco
> > Riosa napisał:
> > > In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized and added
> > > to all python eclasses, it's useful for developers that want test and
> > > mark the package for newer versions of python.
> > > 
> > > However (unless I'm missing something) PYTHON_COMPAT_OVERRIDE is not
> > > usable if:
> > > - the user want only python 2.7 and 3.6 (latest) installed
> > >   no python 3.5
> > > - don't want to mess dependencies (the warnings in the eclass are scary)
> > 
> > Because it is not meant to be used for that purpose, and it is not meant
> > to be used by users at all! It's just a quick hack for developer who
> > wants to UNLIKELY(check if package works with implementation X) before
> > he starts the effort on modifying PYTHON_COMPAT in ebuilds.
> 
> supposed that, but at this point I fail to see the benefit versus the
> added complexity in the eclasses, however that's not my business.
> > 
> > > So, what can be done to let the user choose it's preferred python
> > > version(s) without having to build it's own overlay?
> > > 
> > > One solution is to change ebuilds in tree to include a user variable in
> > > the PYTHON* arrays, example:
> > > 
> > > -PYTHON_COMPAT=( python3_{4,5} )
> > > +PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} )
> > > 
> > > if someone want to bet that packages are ok with 3.6/latest (even before
> > > a developer tested it) then add PYTHON_COMPAT_ADD=python3_6 to
> > > /etc/portage/make.conf and run egencache.
> > > 
> > > Indeed biggest problem in changing $PYTHON* variables is that metadata
> > > also change and cache is invalidated.
> > > 
> > > However if the problem is known (*), and if the change to metadata is
> > > stable per "system"/"gentoo repo clone", then the solution to the
> > > problem is easy; just run $(egencache --update -j$(nproc) --repo gentoo)
> > > after each sync.
> > 
> > This won't work. You are wrongly presuming that egencache regenerates
> > cache unconditionally. It does so only if either ebuild or eclass
> > content changed. So it worked for you once because you modified ebuilds
> > and/or eclasses. It won't work when you change PYTHON_COMPAT_ADD.
> > 
> > I haven't checked the Portage details but it may see the metadata change
> > when installing the package. Which means it would install package with
> > unsatisfied dependencies (because it satisfied dependencies from cache),
> > then store the final dependencies and TADAAM, you've got broken
> > depgraph.
> 
> ouch, that basically kill the proposal, unless portage is modified to
> check known cache modifying variables, which isn't something I'd like to
> create.
> > 
> > > The most important thing is that this solution is scriptable and need no
> > > human intervention.
> > 
> > So is gpy-upgrade-impl.
> 
> It seem to do the job, one piece missing is something that monitor
> gentoo repository to see if it has better version (still w/o wanted
> python), an inotify for ebuilds. Suggestions?

None. I think Alec's idea would work better for you.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] RFC: Bugzilla arch list reordering

[Dirkjan Ochtman]

On Tue, Jan 16, 2018 at 11:19 AM, Michał Górny  wrote:

> I disagree. I think most of the developers are used to the lexical sort,
> and it keeps the order predictable. While I suppose keeping amd64
> and x86 alongside for the sake of being commonly used would make sense,
> I really have no clue how that would affect other arches.
>

It is a trade-off, of course. My hypothesis is that it would be easier to
use.


> By 'frequency' did you mean how many ebuilds are having the specific
> keyword? Could you make some quick stats that would show how this would
> look like right now?
>

Here's an estimation of the relative frequencies:

amd64 (37201)
x86 (33703)
ppc (15347)
arm (14387)
ppc64 (11647)
sparc (10054)
alpha (9219)
ia64 (8456)
hppa (8410)
arm64 (8194)
amd64-linux (7716)
mips (7602)
x86-linux (7409)
x86-fbsd (6102)
sh (4885)
s390 (4421)
ppc-macos (4098)
x86-macos (4028)
amd64-fbsd (3361)
x86-solaris (3202)
x64-macos (3187)
sparc-solaris (2464)
x64-solaris (2208)
m68k (2204)
sparc64-solaris (1344)
arm-linux (1135)
ppc-aix (971)
sparc-fbsd (902)
m68k-mint (626)
x64-cygwin (432)
x86-winnt (123)
x86-interix (5)
x86-cygwin (5)
ia64-hpux (5)
ppc64-linux (4)
arm64-linux (4)
x86-freebsd (1)

Regards,

Dirkjan

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[Róbert Čerňanský]

On Wed, 10 Jan 2018 22:46:04 +0200
Mart Raudsepp  wrote:

> On Wed, 2018-01-10 at 22:38 +0300, Peter Volkov wrote:
> > On Wed, Jan 10, 2018 at 9:31 PM, Aaron W. Swenson
> >  > org> wrote:
> > > Title: GnuCash 2.7+ Breaking Change  
> > 
> > Aaron, but why do we need this news item? 2.7 version is a
> > development version that is not supposed to be used by end users. As
> > far as I understand this backup is a temporary measure until stable
> > release will be out. It's much better to have this version package
> > masked. Then in package mask comment we could note the need for
> > backup.  
> 
> 2.6 is insecure by 400+ ancient webkit-gtk security vulnerabilities,
> we can't responsibly wait anymore. 2.7.3 was tested by Aaron (who
> uses it daily) to work quite nicely.
> I want to last rite gnucash-2.6 used webkit-gtk before the month is
> over, as the maintainer of webkit-gtk, and if 2.7 isn't there, 2.6
> will simply be fully masked as well along it.

I assume that the motivation to get 2.7 stabilized early it to protect
users from potentional damages caused via webkit-gtk security
vulnerabilities.  However, provided that I use GnuCash to display only
local web data (generated reports) I feel much more comfortable
to entrust my data to the stable 2.6 version rather than unstable 2.7
about which the upstream says:

"Unstable (development) releases are for testing purposes only. They
contain the newest features and improvements, but may also contain
serious bugs still. Don't install these releases for everyday use." [1]

"Due to the possibility of data corruption, unstable releases should
only be used on a copy of live GnuCash data." [2]

I think generated reports are typical use of webkit in GnuCash.  Are
attack vectors so severe also in this case?

Thank you.

1. http://gnucash.org/download.phtml
2. https://wiki.gnucash.org/wiki/Development_Process

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[Kristian Fiskerstrand]

On 01/16/2018 03:07 PM, Róbert Čerňanský wrote:
> I think generated reports are typical use of webkit in GnuCash.  Are
> attack vectors so severe also in this case?

Yes, as it would hinder upgrade / keep the vulnerable libraries on the
system that can possibly be used by other packages.

That said, I agree with the overall premise of discussion, and stability
guarantees for the stable keywords, have anyone been in contact with
upstream and discussed the issue of getting a stable release branch not
based on the old webkit?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: vanilla-sources broken

[Holger Hoffstätte]

On 01/05/18 15:08, Nicolas Bock wrote:
> currently vanilla-sources are broken, but there is an upstream patch
> that fixes it (appended at the end). I know that vanilla-sources are
> supposed to be vanilla, but it would help if we added this patch
> until upstream backports it. Any thoughts?

This is now fixed in 4.15-rc8 (with the patch you cited) and will be
in stable 4.14.15 (the one after the upcoming release).

cheers,
Holger

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[Aaron W. Swenson]

On 2018-01-16 15:07, Róbert Čerňanský wrote:
> On Wed, 10 Jan 2018 22:46:04 +0200
> Mart Raudsepp  wrote:
> > 2.6 is insecure by 400+ ancient webkit-gtk security vulnerabilities,
> > we can't responsibly wait anymore. 2.7.3 was tested by Aaron (who
> > uses it daily) to work quite nicely.
> > I want to last rite gnucash-2.6 used webkit-gtk before the month is
> > over, as the maintainer of webkit-gtk, and if 2.7 isn't there, 2.6
> > will simply be fully masked as well along it.
> 
> I assume that the motivation to get 2.7 stabilized early it to protect
> users from potentional damages caused via webkit-gtk security
> vulnerabilities.  However, provided that I use GnuCash to display only
> local web data (generated reports) I feel much more comfortable
> to entrust my data to the stable 2.6 version rather than unstable 2.7
> about which the upstream says:
> 
> "Unstable (development) releases are for testing purposes only. They
> contain the newest features and improvements, but may also contain
> serious bugs still. Don't install these releases for everyday use." [1]
> 
> "Due to the possibility of data corruption, unstable releases should
> only be used on a copy of live GnuCash data." [2]
> 
> I think generated reports are typical use of webkit in GnuCash.  Are
> attack vectors so severe also in this case?
> 
> Thank you.
> 
> 1. http://gnucash.org/download.phtml
> 2. https://wiki.gnucash.org/wiki/Development_Process
> 
> Robert

You are welcome to keep the insecure/outdated packages on your
machine. You do not have to update. We’re just working towards the long
overdue removal of a security risk from the tree.

Really, it isn’t so much that gnucash is at risk because it uses the old
insecure net-libs/webkit-gtk:2 (it may very well be, but there haven’t
been any reports that I’ve seen), but it is all the other packages that
use webkit-gtk to render HTML from untrusted sources that are at risk.

If we could have, we would have removed net-libs/webkit-gtk:{2,3} long
ago. This is nearly two years overdue. [1]

However, this removal will result in it being impossible for anyone to
build gnucash-2.6, so that must be removed as well.

Given the situation, we have a choice: Remove GnuCash altogether, or
press ahead with recommending a version upstream considers unstable.

[1]: https://bugs.gentoo.org/577068


signature.asc
Description: Digital signature

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[Kristian Fiskerstrand]

On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:
> Given the situation, we have a choice: Remove GnuCash altogether, or
> press ahead with recommending a version upstream considers unstable.

Or 3, discuss with upstream to see if they can release an updated
version as stable branch.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: vanilla-sources broken

[Nicolas Bock]

On Tue, Jan 16, 2018 at 03:38:42PM +0100, Holger Hoffstätte wrote:

On 01/05/18 15:08, Nicolas Bock wrote:

currently vanilla-sources are broken, but there is an upstream patch
that fixes it (appended at the end). I know that vanilla-sources are
supposed to be vanilla, but it would help if we added this patch
until upstream backports it. Any thoughts?


This is now fixed in 4.15-rc8 (with the patch you cited) and will be
in stable 4.14.15 (the one after the upcoming release).


Hi Holger,

thanks for the information!

Best,

Nick


cheers,
Holger



--
Nicolas Bock 


signature.asc
Description: PGP signature

[gentoo-dev] Re: [PATCH] linux-mod.eclass: IUSE default support for MODULES_OPTIONAL_USE

[Martin Vaeth]

Robin H. Johnson  wrote:
> That is counter-intuitive for somebody that puts
> MODULES_OPTIONAL_USE_IUSE_DEFAULT=0
> Or tries to otherwise have it unset.

What I usually do is:

case ${MODULES_OPTIONAL_USE_IUSE_DEFAULT:-n} in
  [nNfF]*|[oO][fF]*|0|-)  # false case
;;
  *) # true case
esac

This covers most of the "intuitive" attempts (0 - Off FALSE no ...)
to switch it off, and everything else (nonempty) means "on".

[gentoo-dev] Re: News Item: GnuCash 2.7+ Breaking Change

[Duncan]

Kristian Fiskerstrand posted on Tue, 16 Jan 2018 15:58:11 +0100 as
excerpted:

> On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:
>> Given the situation, we have a choice: Remove GnuCash altogether, or
>> press ahead with recommending a version upstream considers unstable.
> 
> Or 3, discuss with upstream to see if they can release an updated
> version as stable branch.

This reminds me very much of the long-time stability situation with 
grub-0.9x vs. 1.9x.  Upstream insisted 0.9x was unsupported, and indeed, 
had abandoned it, such that it was the distros carrying upstream-
unapproved patches, but at the same time, pre-2.0 as 1.9x was still very 
much development-only and not ready for prime-time, according to 
upstream.  Just what were distros and users /supposed/ to do?

Both that and this gnucash thing are bad situations all around, but 
perhaps some lessons can be had.  And agreed that surely the first must 
be to /just/ /ask/ upstream whether they can release something stable 
that's at least based on something still getting maintenance, security 
and otherwise.  Then go from there.  Maybe they'll refuse and we'll have 
to move ahead with the new version regardless of upstream's wishes, but 
we'll never know if we don't ask.

(Of course it can go the other way too, upstream insisting the new 
version is stable even when it's still broken for normal users every 
which way to Sunday.  The kde3/kde4 transition is a prime example of 
that.  I honestly don't know which is worse, but the obvious ideal is a 
sane upstream that doesn't veer to either extreme, or lacking that, at 
least cooperates and provides support when a new at least /semi-/stable 
release is needed as the old is just outdated and broken, security or 
otherwise.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[Róbert Čerňanský]

On Tue, 16 Jan 2018 15:58:11 +0100
Kristian Fiskerstrand  wrote:

> On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:
> > Given the situation, we have a choice: Remove GnuCash altogether, or
> > press ahead with recommending a version upstream considers
> > unstable.  
> 
> Or 3, discuss with upstream to see if they can release an updated
> version as stable branch.

4. Mask the vulnerable webkit-gtk.  This way: A. User is informed.
B. Manual action is required to continue using such package.

I see this as the most obvious choice considering that I am still
unable to find any possible attack vector against GnuCash.  If it is me
and only me who enters data.  Webkit reports are generated from those
data.  How can anyone hack me through GnuCash?

In general, many times users use applications in a way that
vulnerabilities does not apply to their use cases.  I would prefer to
be informed and allowed to continue using such application as a part of
the distro.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[M. J. Everitt]

On 16/01/18 21:56, Róbert Čerňanský wrote:
> On Tue, 16 Jan 2018 15:58:11 +0100
> Kristian Fiskerstrand  wrote:
>
>> On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:
>>> Given the situation, we have a choice: Remove GnuCash altogether, or
>>> press ahead with recommending a version upstream considers
>>> unstable.  
>> Or 3, discuss with upstream to see if they can release an updated
>> version as stable branch.
> 4. Mask the vulnerable webkit-gtk.  This way: A. User is informed.
> B. Manual action is required to continue using such package.
>
> I see this as the most obvious choice considering that I am still
> unable to find any possible attack vector against GnuCash.  If it is me
> and only me who enters data.  Webkit reports are generated from those
> data.  How can anyone hack me through GnuCash?
>
> In general, many times users use applications in a way that
> vulnerabilities does not apply to their use cases.  I would prefer to
> be informed and allowed to continue using such application as a part of
> the distro.
>
> Robert
>
>
Forgive my potential misunderstanding here .. but who's actively
preventing you from using GnuCash 2.6? You can take a copy locally to
/usr/local/portage so that When/If finally it gets removed from the
central package 'tree' it will run for you provided its requirements are
still met on your system ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[Róbert Čerňanský]

On Tue, 16 Jan 2018 22:19:15 +
"M. J. Everitt"  wrote:

> On 16/01/18 21:56, Róbert Čerňanský wrote:
> > On Tue, 16 Jan 2018 15:58:11 +0100
> > Kristian Fiskerstrand  wrote:
> >  
> >> On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:  
> >>> Given the situation, we have a choice: Remove GnuCash altogether,
> >>> or press ahead with recommending a version upstream considers
> >>> unstable.
> >> Or 3, discuss with upstream to see if they can release an updated
> >> version as stable branch.  
> > 4. Mask the vulnerable webkit-gtk.  This way: A. User is informed.
> > B. Manual action is required to continue using such package.
> >
> > I see this as the most obvious choice considering that I am still
> > unable to find any possible attack vector against GnuCash.  If it
> > is me and only me who enters data.  Webkit reports are generated
> > from those data.  How can anyone hack me through GnuCash?
> >
> > In general, many times users use applications in a way that
> > vulnerabilities does not apply to their use cases.  I would prefer
> > to be informed and allowed to continue using such application as a
> > part of the distro.
> >
> > Robert
> >
> >  
> Forgive my potential misunderstanding here .. but who's actively
> preventing you from using GnuCash 2.6? You can take a copy locally to
> /usr/local/portage so that When/If finally it gets removed from the
> central package 'tree' it will run for you provided its requirements
> are still met on your system ...

That's correct, nobody is preventing me and I already have copies of
several packages.  But with each additional package Gentoo becomes less
and less valuable.  You can say the same thing about every package.  But
what would be the point of linux distribution then?

I worked with assumption that there is a motivation in Gentoo to provide
a value in a form of stable GnuCash and I merely presented a way which I
see as most pragmatic.  It allows to continue to provide that value and
raises awarenes about webkit-gtk security vulnerabilities.

Of course there is also a possibility that maintainters may have lost
interest/motivation to maintain old webkit-gtk.  Which would be normal
and prefectly fine but completelly different matter than security.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk