Removal of gconf dependency?
-
Does anyone know when the dependency to (deprecated) gconf will be dropped? I was eager to take a look at this, but our security policy no longer allows gconf to be installed, and Vivaldi won't even start without it. Thanks.
-
It'd be strange if Vivaldi actually stored anything using GConf, so it shouldn't be too difficult to remove the dependency.
-
Vivaldi depends on gconf-service.
debian jessie 8.4
-
vivaldi-snapshot_1.2.479.8-1_amd64.deb requires:
gconf-service
libgconf-2-4 (>= 2.31.1)vivaldi-snapshot-1.2.479.8-1.x86_64.rpm requires:
libgconf-2.so.4()(64bit)Note that according to the original poster the program doesn't start without GConf, so the dependencies in the packages are not superfluous.
-
I guess my question is not so much "why is gconf listed as a dependency" (I ran ldd after I downloaded it - before I even attempted to run it, and saw that is was compiled needing that library), but why is Vivaldi using gconf at all? It is deprecated and unmaintained. As I said in my original post, our security policy no longer allows it. I really want to try Vivaldi (but not so much that I am going to go through the effort of setting up a new personal system just to give it a test drive ).
Almost all of gnome has migrated to gsettings:
https://wiki.gnome.org/Initiatives/GnomeGoals/GSettingsMigration
-
I've read that Chromium includes several custom libraries that have been forked from upstream and not necessarily kept up to date. This is one of the main reasons that packagers of distributions such as Fedora dislike Chromium. Vivaldi inherits these out-of-date pieces of code from Chromium.
-
I just registered to post about the GConf thing.
Chromium can be compiled with GConf disabled.
The dependency is pointless nowadays since everything in existence was migrated in GSettings. Hence the ability to read GConf settings is pointless. It is not going to be used anyway.
There should be a -Duse_gconf=0 make option if this is a straight Chromium fork.
Thank you. -
I've read that Chromium includes several custom libraries that have been forked from upstream and not necessarily kept up to date. This is one of the main reasons that packagers of distributions such as Fedora dislike Chromium. Vivaldi inherits these out-of-date pieces of code from Chromium.
I think you have that backwards. My understanding is that Chromium IS upstream. See:
https://en.wikipedia.org/wiki/Chromium_(web_browser)
I just registered to post about the GConf thing.
Chromium can be compiled with GConf disabled.
The dependency is pointless nowadays since everything in existence was migrated in GSettings. Hence the ability to read GConf settings is pointless. It is not going to be used anyway.
There should be a -Duse_gconf=0 make option if this is a straight Chromium fork.
Thank you.Thank you for registering to comment.
If Vivaldi can be compiled without gconf (especially if it is, as you say, pointless), then it clearly should be (hoping the right people see this).
-
My understanding is that Chromium IS upstream.
Chromium is upstream for Vivaldi, but several libraries by third parties are upstream for Chromium.
-
Still waiting for a snapshot that doesn't depend on gconf.
-
Bitterly disappointed that this hasn't been fixed in 1.3.
REALLY want to try Vivaldi, but I won't be able to until it is compiled without being linked to libgconf.
-
What's the status on this particular issue? Did anybody file a bug report? It seems pretty important to me.
-
Hi, we are looking into this. Back in June this was investigated and one of our devs found that too much of chromium actually depends on this for it do easily be disabled. We are taking another look now as it seems to be preventing some users from using Vivaldi
-
Want to bump this up to the front page, since the forum seems much more active now.
Seems there is still no progress on this.
Has anyone tried compiling Vivaldi without gconf, and testing that?
-
@HussamT said in Removal of gconf dependency?:
There should be a -Duse_gconf=0 make option if this is a straight Chromium fork.
This is the reason I prefer open source - I could compile it myself, and see whether it worked or not.
Has anyone at Vivaldi actually tried a simple:
"make -Duse_gconf=0"
and if so, what was the result?
-
@Gwen-Dragon said in Removal of gconf dependency?:
@0001 Yes, this flag is known.
I ask a developer regarding bug VB-17650 with gconf dependecy.So what was the result when Vivaldi was compiled with "make -Duse_gconf=0"? Was there any problem? Is there any update on this bug?
-
We haven't looked into this as earlier stated. We consider it a low priority.
-
You are dynamically linking to deprecated and unmaintained software, which causes problems (including potential security issues), and will cause additional trouble in the future as more and more distributions simply stop providing gconf.
The cost in resources of a cursory evaluation is minimal. Just build Vivaldi with -Duse_gconf=0, and see if it works (maybe you have a test suite or something).
-
@dLeon said in Removal of gconf dependency?:
While it's true libgconf/gconf deprecated, it is not have security issues in the sense Distro package maintainers will make sure that won't happen.
Security vulnerabilities have to be found in order to be fixed, and with no developers looking at the gconf code, that is less likely to happen.
@dLeon said in Removal of gconf dependency?:
The only flaw it cause is people with Distro who prematurely dare to kick gconf and co. can not install Vivaldi.
You forgot organization (government, corporate, and education) IT departments that set policies allowing what software can be installed. In my case, gconf is FORBIDDEN BY SECURITY POLICY (the IT department here takes a very dim view of allowing deprecated and unmaintained software on machines).
@dLeon said in Removal of gconf dependency?:
As per today Debian sid, libgconf still depended by:
Google Chrome, Opera, PulseAudio, OpenJDK, Emacs, Gnome Terminal, etc.Sounds rather archaic. We compile from source whenever possible. NONE of the above packages that can be required from source (including Gnome Terminal, which would install nearly 200 new packages on a typical machine, including things we never would use, such as systemd, pam, and pulseaudio) require gconf (binary packages which have been foolishly linked to it, of course do).
@dLeon said in Removal of gconf dependency?:
As can you see, those are a serious packages. Distro maintainers will tear blood before security breach happen.
Distro managers are cursing upstream developers who force them to continue to maintain obsolete packages (which are of course, in addition to current packages).
@dLeon said in Removal of gconf dependency?:
And really about security, gconf basically a config manager.
Configuration managers are actually an effective attack vector for taking control of a system.
I simply don't understand Vivaldi's resistance to doing a compile with a well-known and well-supported flag, and observing the results.
-
Another year on, and no progress whatsoever. I do notice that the gentoo ebuilds for Chromium have not allowed gconf to be linked in for many months. And recently, as of Chromium-65.0.3315.3, there are no references to gconf in the ebuild at all. Gconf has been deprecated for more than six years now - it is long past time to kill it. Maybe they (finally!) have
@dleon said in Removal of gconf dependency?:
It's my curiosity.
Usually, within such mentioned organization and the type of "from source only policy", they would do a lock down with what softwares their worker could use.
It's not a matter "because it use deprecated libs" anymore, 3rd party browsers brought by the worker and fast moving development such Firefox non ESR, Chrome or Vivaldi usually a big no no from the start."Fast moving" developments tend to fix problems with their code. No one has done anything with the gconf code for several years.
@dleon said in Removal of gconf dependency?:
Configuration managers are actually an effective attack vector for taking control of a system.
If attackers could access organization configs, that organization got bigger problem.
It is obvious you don't know much about security issues and attack vectors. If someone can gain control of the configuration manager, they can link in other (users, perhaps) files on the system, and initiate any number of methods to undermine the integrity of the system.
@dleon said in Removal of gconf dependency?:
Because no developers, it doesn't mean dead. This is Linux we're talking about.
No developers means no one is looking at the code.
@dleon said in Removal of gconf dependency?:
All the rest depend to Distro/package maintainer. Are they eager to provide bug/security fix? If the answer is yes, then the package will continue.
Yeah, if someone else finds a bug, they will integrate a patch (but they aren't looking for bugs - NOBODY is looking for bugs).
@dleon said in Removal of gconf dependency?:
Some of applications still alive/offered in rolling/futuristic distro such as Arch or Gentoo could be consider as dead because upstream developers didn't care anymore. Notably, some Window Manager and Display Manager. But the package maintainers & co. eager to send bug/security fix to it.
I am quite involved in Gentoo, and that is not the way it works. Unmaintained packages get removed from the tree as soon as practical (ie. alternatives are available).
"Occasionally" someone may care enough about a package to maintain it himself (or herself). It that case, it still gets removed from the main portage tree, and is available only via a private repository.
And no one is "eager" to fix dead software. It is done only out of necessity.
@dleon said in Removal of gconf dependency?:
In "All from source" type organization, the Distro could be called "organization IT departement Distro". And guess who's the package maintainer.
I don't want to be working with dead software. Compiling currently maintained packages (and keeping up with security issues) is enough work. If upstream (the coders that created the software) aren't going to take care of it anymore, I certainly don't have the time nor ability to do so.
Most others (distribution maintainers, package maintainers, and other other projects that depend on it) should not waste their time on it either, and remove it.
Again, virtually every other piece of software I am familiar with migrated away from gconf years ago. It is past time for Vivaldi to do the same.
-