ChromeDriver version 87.0.4280.88 has been released
206 views
Skip to first unread message
Shengfa Lin
Dec 2, 2020, 12:02:50 PM12/2/20
to ChromeDriver Users
Hello ChromeDriver users,
We are happy to announce that ChromeDriver version 87.0.4280.88 has been released, and is now available at the ChromeDriver Downloads site. This version of ChromeDriver is intended to address rendering issues for background browsers on Windows.
Changes in this version of ChromeDriver include:
- Resolved issue 3641: Page not getting loaded/rendered when browser window is not in focus with Chrome Beta v87 and chromedriver v(87/86)
- Resolved issue 3657: Screenshot background browser timed out
Please see the release notes for a more complete list of changes included in this release.
Thanks for your continued support of ChromeDriver, and please let us know if you have any questions.
Sincerely,
ChromeDriver Team
Michael Weiss
Dec 8, 2020, 8:25:09 AM12/8/20
to ChromeDriver Users
Hi,
apparently the ZIP archive for this release [0] was updated (modified) after the initial release. I noticed this because I package ChromeDriver for Nix(OS). As it is usual for Linux distributions we use hashes when downloading sources. This means that, as a result, builds will fail if the hash of the ZIP archive changes. Unfortunately this is what happened when I packaged this release (details, including the diffoscope output: [1]).
Do you know what caused this update that changed the timestamp of the chromedriver file from 20-Dec-02 16:42 to 20-Dec-03 18:14 (maybe CI is generating and pushing the ZIP archive twice?) and would it be possible to prevent such updates in the future? Keeping the published source archives immutable would be important for both Linux distributions and Reproducible Builds [2] in general.
Kind regards and thanks in advance,
Michael Weiss
Jan 7, 2021, 5:47:37 AM1/7/21
to ChromeDriver Users
Any updates? We just noticed this again: https://github.com/NixOS/nixpkgs/pull/108631#issuecomment-755837258
Shengfa Lin
Jan 7, 2021, 11:56:57 AM1/7/21
to ChromeDriver Users
Hi Michael,
First of all, sorry for the inconvenience that the updated ZIP archive has brought you.
The reason that the hash of the ZIP archive changes is because of manual run of our release script.
The reason for the change for yesterday is because of the release for Mac m1 binary for ChromeDriver.
The release script simply upload and overwrite the binaries for Windows, Linux and Mac which we thought would be safe to do.
I did notice yesterday that only the hash of Linux binary changes but not the Windows and Mac.
Is that what you have observed as well?
I can look into why the hash for Linux changes when it's regenerated. Besides from the hash, does the change of update timestamp has an impact on your workflow?
We would like to evaluate if we can do the overwrite release in the future.
Best,
Shengfa
Michael Weiss
Jan 7, 2021, 2:20:22 PM1/7/21
to Shengfa Lin, ChromeDriver Users
Hi Shengfa,
On Thu, 07 Jan, 2021 at 08:56:57 -0800, 'Shengfa Lin' via ChromeDriver Users wrote:
> The release script simply upload and overwrite the binaries for Windows,
> Linux and Mac which we thought would be safe to do.
yes, for normal users this should be safe to do (and to be honest Linux
distributions that care about reproducibility should build it from
source anyway). However, IMO it would be best to never modify uploaded
releases and instead release a new version (patch release).
> I did notice yesterday that only the hash of Linux binary changes but not
> the Windows and Mac.
> Is that what you have observed as well?
Yes, we don't fetch the Windows archive but the content/hash of the Mac
archive didn't change.
> I can look into why the hash for Linux changes when it's regenerated.
Thanks!
> Besides from the hash, does the change of update timestamp has an impact on
> your workflow?
No, but unfortunately in our case the hash change is enough to break the
package build. If the fetched source doesn't match the expected hash it
is rejected and the "build" fails (this is done to ensure
reproducibility and as an additional measure to prevent MITM attacks).
This should apply to most other Linux distributions as well (if they
don't build from source). E.g. here's a comment on the AUR package:
https://aur.archlinux.org/packages/chromedriver/#comment-784931
Not modifying uploaded archives also helps with trust and caching. E.g.
if the content/hash changes it is not immediately clear what has changed
and why (it could e.g. be a MITM attack, a targeted attack (serving a
different archive to certain users), or a hijacked web server).
For that reason alone it is IMO very important to never modify already
uploaded/published releases.
> We would like to evaluate if we can do the overwrite release in the future.
This is of course your decision but if I may ask is there any advantage
of overwriting releases instead of making a new patch release?
The potential advantages I could think of:
- It saves storage on the hosting service
- But I'm not sure if that's a concern/issue for you
- If users that have already downloaded the old archive shouldn't have
to download the new/modified one
- But then the question is if the new archive/upload is really
required in the first place
Kind regards,
Michael
On Thu, 07 Jan, 2021 at 08:56:57 -0800, 'Shengfa Lin' via ChromeDriver Users wrote:
> The release script simply upload and overwrite the binaries for Windows,
> Linux and Mac which we thought would be safe to do.
distributions that care about reproducibility should build it from
source anyway). However, IMO it would be best to never modify uploaded
releases and instead release a new version (patch release).
> I did notice yesterday that only the hash of Linux binary changes but not
> the Windows and Mac.
> Is that what you have observed as well?
archive didn't change.
> I can look into why the hash for Linux changes when it's regenerated.
> Besides from the hash, does the change of update timestamp has an impact on
> your workflow?
package build. If the fetched source doesn't match the expected hash it
is rejected and the "build" fails (this is done to ensure
reproducibility and as an additional measure to prevent MITM attacks).
This should apply to most other Linux distributions as well (if they
don't build from source). E.g. here's a comment on the AUR package:
https://aur.archlinux.org/packages/chromedriver/#comment-784931
Not modifying uploaded archives also helps with trust and caching. E.g.
if the content/hash changes it is not immediately clear what has changed
and why (it could e.g. be a MITM attack, a targeted attack (serving a
different archive to certain users), or a hijacked web server).
For that reason alone it is IMO very important to never modify already
uploaded/published releases.
> We would like to evaluate if we can do the overwrite release in the future.
of overwriting releases instead of making a new patch release?
The potential advantages I could think of:
- It saves storage on the hosting service
- But I'm not sure if that's a concern/issue for you
- If users that have already downloaded the old archive shouldn't have
to download the new/modified one
- But then the question is if the new archive/upload is really
required in the first place
Kind regards,
Michael
Shengfa Lin
Jan 7, 2021, 3:37:22 PM1/7/21
to ChromeDriver Users
Hi Michael,
We have made a change to our release script so that in the future the binaries for the same version on a particular platform should have the same hash (when they are being overwritten).
Thanks,
Shengfa
Reply all
Reply to author
Forward
0 new messages