Package Details: google-chrome 131.0.6778.85-1

Git Clone URL: https://aur.archlinux.org/google-chrome.git (read-only, click to copy)
Package Base: google-chrome
Description: The popular web browser by Google (Stable Channel)
Upstream URL: https://www.google.com/chrome
Keywords: chromium
Licenses: custom:chrome
Submitter: None
Maintainer: gromit
Last Packager: gromit
Votes: 2246
Popularity: 8.78
First Submitted: 2010-05-25 20:25 (UTC)
Last Updated: 2024-11-19 19:19 (UTC)

Dependencies (12)

Sources (3)

Pinned Comments

gromit commented on 2023-04-15 08:22 (UTC) (edited on 2023-05-08 21:42 (UTC) by gromit)

When reporting this package as outdated make sure there is indeed a new version for Linux Desktop. You can have a look at the "Stable updates" tag in Release blog for this.

You can also run this command to obtain the version string for the latest chrome version:

$ curl -sSf https://dl.google.com/linux/chrome/deb/dists/stable/main/binary-amd64/Packages | \
     grep -A1 "Package: google-chrome-stable" | \
     awk '/Version/{print $2}' | \
     cut -d '-' -f1

Do not report updates for ChromeOS, Android or other platforms stable versions as updates here.

Latest Comments

« First ‹ Previous 1 .. 87 88 89 90 91 92 93 94 95 96 97 .. 157 Next › Last »

Det commented on 2015-02-12 07:13 (UTC)

It's because of: warning: directory permissions differ on /usr/share/doc/google-chrome-stable/ filesystem: 700 package: 755 Since it's a directory, the permission can't be automatically changed by the: msg2 "Fixing permissions of documentation folder..." chmod 755 "$pkgdir"/usr/share/doc/google-chrome-$_channel/

Moviuro commented on 2015-02-12 07:07 (UTC)

Hi there, Looks like the following folder has wrong permissions: drwx------ 1 root root 24 Jan 29 11:35 /usr/share/doc/google-chrome-stable Anyway, thanks for the package ;)

Det commented on 2015-02-11 13:30 (UTC)

@mgb, that's for Chrome OS: http://googlechromereleases.blogspot.com

Det commented on 2015-02-07 17:10 (UTC)

This is true.

weirddan455 commented on 2015-02-07 17:01 (UTC)

We're getting the checksum from you though, not from Google, and you have nothing from Google to verify the file against. If someone were to replace the file on Google's server with a malicous one (which, yes, is unlikely but not impossible. Google could be hit with a 0 day vaunerability just like anyone else) then you would update the checksum on the PKGBUILD thinking the file was legitamite. That only needs one point of entry. If Google were using PGP signautures then that would require two points of entry. The attacker would have to both replace the file AND steal Google's private key to sign the file.

Det commented on 2015-02-07 16:36 (UTC)

@weirddan455, that's assuming, of course, that you'd be able to break into two distinct places. The only practical way to do Google is to be walking into the server room, hogging a few, and coming up with a great excuse. @ilpianista, are you using Manjaro, or did you touch the line below "Symlinking missing Udev lib..."?

ilpianista commented on 2015-02-07 16:26 (UTC)

/opt/google/chrome/chrome: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory

weirddan455 commented on 2015-02-07 14:28 (UTC)

Any checksum, no matter the algorithm, won't protect you from someone malicously altering the file. Reason being is that if someone manages to replace the file you're downloading it probably wouldn't be too hard for them to simply replace the checksum as well to match the malicous file. The only thing the checksum is good for the way we use it here is to protect against accidental data corruption during the download. MD5 will work just fine for that. Hell even CRC would probably do the job. If you want real data integrety protection, we really PGP signatures. Sadly I don't think Google signs their Chrome DEBs though.

« First ‹ Previous 1 .. 87 88 89 90 91 92 93 94 95 96 97 .. 157 Next › Last »