This restores the Python wheel CI runs from the old upb repo with only minor
changes. I had to update a path in one of the `py_wheel` rules and also make a
slight tweak to ensure that the `descriptor.upb_minitable.{h,c}` files make it
into the source wheels. The change in text_format_test.py is not strictly
necessary but is a small simplification I made while I was trying to debug an
issue with CRLF newlines.
I had to update test_util.py to use `importlib` to access the golden files from
the installed `protobuftests` package. I suspect the previous incarnation of
thse test runs was somehow reading the goldens from the repo checkout, but I
think the intention is to read them from `protobuftests` instead. This was a
bit tricky to get working because Python versions before 3.9 do not support
`importlib.resources.files()`. I set up the code to fall back on
`importlib.resources.open_binary()` in that case, but that function does not
support subdirectories, so this required putting an `__init__.py` file inside
the `testdata` directory to make sure it is treated as a Python package.
PiperOrigin-RevId: 567366695
I am getting ready to move almost everything under the upb/ directory up one
level to integrate upb better into its new location in the protobuf repo. This
change makes a few tweaks to prepare for that:
- Delete upb's LICENSE and CONTRIBUTING.md files since we already have similar
files at the top level.
- Rename `//python:python_version` so that it won't conflict later with
`//upb/python:python_version`.
- Move the contents of python/BUILD.bazel out to a Bazel macro to facilitate
merging that BUILD.bazel file with upb/python/BUILD.
PiperOrigin-RevId: 567119840
This restores a CI run that used to exist in the upb repo. I still need to add
test runs to exercise the wheels, but this change adds the functionality for
building and uploading them.
PiperOrigin-RevId: 564896637
A couple weeks ago we moved upb into the protobuf Git repo, and this change
continues the merger of the two repos by making them into a single Bazel repo.
This was mostly a matter of deleting upb's WORKSPACE file and fixing up a bunch
of references to reflect the new structure.
Most of the changes are pretty mechanical, but one thing that needed more
invasive changes was the Python script for generating CMakeLists.txt,
make_cmakelists.py. The WORKSPACE file it relied on no longer exists with this
change, so I updated it to hardcode the information it needed from that file.
PiperOrigin-RevId: 564810016
It seems that the janitor.yml workflow only needs pull-requests: write permission -- to close the PRs. I've also granted the contents: read just in case.
PiperOrigin-RevId: 561444486
This removes the need for us to manually rebuild these amalgamation files. I
added the "manual" tag to the corresponding staleness tests so that we won't
get presubmit errors if the amalgamation files are out of date. I also had to
tweak the Ruby BUILD.bazel file to make sure it uses Bazel-generated
amalgamations instead of relying on the checked-in files.
I added deliberate errors to the Ruby and PHP amalgamation files to test that
everything is working. We should not see any CI errors, and the files should
quickly be auto-updated after the change lands on main.
PiperOrigin-RevId: 561187352
## Description
I would like to suggest a security practice recommended by the [OpenSSF Scorecard][scorecard-repo] which is to hash pin dependencies to prevent typosquatting and tag renaming attacks.
The change would only be applied to GitHub workflows.
This means hash pinning GitHub Workflow actions.
Along with hash-pinning dependencies, I also recommend adopting dependabot (or other dependency update tool) to help keep the dependencies up to date. Most tools can update hashes and associated semantic version comments.
Any questions or concerns just let me know.
Thanks!
## Additional Context
A tag renaming attack is a type of attack whereby an attacker:
- Hijack an action.
- Upload a malicious version.
- Replace existing tags with malicious versions.
A [typosquatting attack][typosquatting] is a type of attack whereby an attacker:
- Create a malicious package
- Publish it with a similar name of a known package (example: numpi instead of numpy)
For more informations about the dependency-update tools:
- [Dependabot][dependabot]
[scorecard-repo]: https://github.com/ossf/scorecard
[deps-confusion]: https://www.websecuritylens.org/how-dependency-confusion-attack-works-and-how-to-prevent-it/
[typosquatting]: https://snyk.io/blog/typosquatting-attacks/
[dependabot]: https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/
[renovatebot]:https://www.mend.io/renovate/
PiperOrigin-RevId: 561019142
Currently all our upb CI coverage is running from within the protobuf workspace
and referring to upb as the external repo `@upb`. This change makes the GCC
test run cd into upb and use its workspace instead, just to make sure that
builds in the upb workspace have some coverage.
PiperOrigin-RevId: 560197956
This test validates that upb Python targets can be built successfully even if
Python is not installed locally.
I also updated our pinned upb version to pull in some recent fixes needed for
this test run.
PiperOrigin-RevId: 559504790
This change adds test runs for GCC, Windows, and Mac. The 32-bit ASAN test
turned out to be somewhat difficult to migrate, so I left a TODO for that one.
I made sure to give each build environment its own cache prefix, so that we
don't end up with artifacts built by different toolchains conflicting with each
other in the same cache.
PiperOrigin-RevId: 559197655
There are still a bunch more test runs to migrate, but this change adds a few
more that were unblocked by the `exclude-targets` flag.
PiperOrigin-RevId: 558206606
My editor reformatted this file to add a missing newline, and this ended up
breaking the test. The added newline caused there to be a newline in the middle
of the Bazel command. So this change adds the missing newline and fixes up the
Bazel command by using the `>-` syntax to treat this as a multiline string
without adding any newlines.
PiperOrigin-RevId: 558149295
This change moves the upb Fastbuild, Optimized, and FastTable test runs over to
the protobuf repo CI in preparation for moving the upb codebase itself. There
are a bunch more test runs to move, but this initial change handles the easy
ones first.
I also updated our pinned upb version to the current head to pick up some
recent fixes.
PiperOrigin-RevId: 557486174
https://github.com/protocolbuffers/protobuf/pull/13204 refactored the Ruby object cache to use a key of `LL2NUM(key_val)` instead of `LL2NUM(key_val >> 2)`. On 32-bit systems, `LL2NUM(key_val)` returns inconsistent results because a large value has to be stored as a Bignum on the heap. This causes cache lookups to fail.
This commit restores the previous behavior of using `ObjectCache_GetKey`, which discards the lower 2 bits, which are zero. This enables a key to be stored as a Fixnum on both 32 and 64-bit platforms.
As https://patshaughnessy.net/2014/1/9/how-big-is-a-bignum describes, a Fixnum uses:
* 1 bit for the `FIXNUM_FLAG`.
* 1 bit for the sign flag.
Therefore the largest possible Fixnum value on a 64-bit value is 4611686018427387903 (2^62 - 1). On a 32-bit system, the largest value is 1073741823 (2^30 - 1).
For example, a possible VALUE pointer address on a 32-bit system:
0xff5b4af8 => 4284173048
Dropping the lower 2 bits makes up for the loss of range to these flags. In the example above, we see that shifting by 2 turns the value into a 30-bit number, which can be represented as a Fixnum:
(0xff5b4af8 >> 2) => 1071043262
This bug can also manifest on a 64-bit system if the upper bits are 0xff.
Closes#13481Closes#13494
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/13494 from stanhu:sh-fix-ruby-protobuf-32bit d63122a6fc
PiperOrigin-RevId: 557211768
Clang and GCC differ on how they detect Address Sanitizer. Support both.
Closes#1424
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/upb/pull/1424 from protocolbuffers:asan-clang 491a5ee4cfd24c8eb281f894de0cf4384525c46a
PiperOrigin-RevId: 553805994
This flag was added to Protobuf and submitted separately due to version skew between repos.
This attempts to fix the following error from local and release settings both matching.
```
ERROR: /workspace/_build/out/external/upb/python/dist/BUILD.bazel:251:9: Illegal ambiguous match on configurable attribute "platform" in @upb//python/dist:binary_wheel:
@upb//python/dist:linux_x86_64_local
@upb//python/dist:windows_x86_64
Multiple matches are not allowed unless one is unambiguously more specialized or they resolve to the same value. See https://bazel.build/reference/be/functions#select.
```
PiperOrigin-RevId: 553226261
Mike Kruskal
Sandy Zhang
Adam Cozzette
Protobuf Team Bot
dependabot[bot]
Joshua Haberman
Eric Salo
Stan Hu
Jason Lunn