Package Details: google-chrome 130.0.6723.116-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: 2243
Popularity: 7.00
First Submitted: 2010-05-25 20:25 (UTC)
Last Updated: 2024-11-05 19:02 (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 »

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.

Det commented on 2015-02-07 05:38 (UTC)

We can learn something new every day, but now that the aftermath of my controversial and time-consuming edit[1] for our awesome Wiki admin, Kynikos, has been settled[2], I've now explained the differences between collision and preimage vulnerabilities in MD5, SHA-1 and SHA-2 in the PKGBUILD article: https://wiki.archlinux.org/index.php/PKGBUILD#Integrity_variables This took quite a bit of researching, but it basically means that having MD5 checksums for file integrity are actually fine for now. You don't want to use it for SSL certificates, but carrying out a successful preimage attack requires, even in theory, approximately 2^123.4 ≈ 1.4 × 10^37 operations, which is completely impractical. [1] = https://wiki.archlinux.org/index.php?title=PKGBUILD&diff=359592&oldid=359584 [2] = https://wiki.archlinux.org/index.php/Talk:PKGBUILD#pkgdir

tormund commented on 2015-02-06 18:10 (UTC)

Latest release won't let you press enter to search terms in the omnibox, but it will let you go to suggested websites.

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