The old code could potentially yield to a use-after-free situation,
which results in UB. For this, consider the following scenario, where
osc performs several HTTPS requests (assumption: the server supports
ssl session resumption):
- HTTPS Request 1:
* a new SSL *s connection is established, which also creates a new
SSL_SESSION *ss => ss->references == 1
* once the handshake is done, the ss is put into the session cache
(see ssl_update_cache) => ss->references == 2
- osc saves the session ss in a class variable
- s is SSL_free()d, which calls SSL_SESSION_free => ss->references == 1
- HTTPS Request 2:
* setup a new SSL *s connection that reuses the saved session ss
=> ss->references == 2
* once the handshake is done, ssl_update_cache is called, which is a
NOP, because s->hit == 1 (that is, the session was resumed)
* osc saves the session ss in a class variable
* s is SSL_free()d, which calls SSL_SESSION_free => ss->references == 1
...
> 2 hours later (see tls1_default_timeout)
...
- HTTPS Request 256:
* setup a new SSL *s connection that reuses the saved session ss
=> ss->references == 2
* once the handshake is done, ssl_update_cache is called, but is
_no_ NOP anymore
* ssl_update_cache flushes the session cache (this is done every
255/256 (depending on the way we count) connections) => ss is
SSL_SESSION_free()d => ss->references == 1
* osc saves the session ss in a class variable
* s is SSL_free()d, which calls SSL_SESSION_free:
since ss->references == 1, ss is eventually free()d
- HTTPS Request 257:
* setup a new SSL *s connection that reuses the saved session ss
Since ss does not exist anymore, the remaining program execution is UB.
(Note: SSL_free(...) is _NOT_ called, if M2Crypto 0.29 is used.
M2Crypto 0.30 calls SSL_free(...) again.)
Due to a bug in OpenSSL_1_1_0h (see openssl commit 8e405776858) the
scenario from above can be triggered with exactly 2 HTTPS requests (the
SSL_SESSION is not cached, because we configured SSL_VERIFY_PEER, but
no sid_ctx was set). This is fixed in openssl commit c4fa1f7fc01.
In order to reliably reuse a session, we probably need to listen to the
session cache changes. Such callbacks could be registered via
SSL_CTX_sess_set_new_cb and/or SSL_CTX_sess_set_remove_cb, but both
functions are not provided by M2Crypto. Another idea is to directly utilize
the session cache, but this also has to be implemented in M2Crypto first.
Yet another approach is to retrieve the session via SSL_get1_session, which
increases the session's refcnt, but this also needs to be implemented in
M2Crypto first (if we choose to use this approach, we also have to make
sure that we eventually free the session manually...).
Fixes: #398 ("SIGSEGV on \"osc commit\"")
Always pass the "--statistics" option to the build script (only affects
a vm build). It is not implemented as an option, because we already have
so many of them... (see also https://github.com/openSUSE/osc/pull/412).
yet another option, but
* only very old build scripts don't know it, we should just require a recent one
* build script is ignoring it for chroot case
so why bother with another option?
Note that the diff is only shown, if it was requested before (that is
the "i" command was issued). The new behavior is consistent with the
other commands like "a", "d" etc.
Storing the error encoding in an "encoding" attribute "breaks" the
python3 "input" function: In essence, builtin_input_impl does a
getattr(sys.stdout, 'encoding'), which returns our error encoding
instead of the "real" stdout encoding. In order to avoid this, we
store the error encoding in an "_encoding" attribute.
Making SafeWriter a new-style class simplifies the code a lot.
This is a fix for issue #385. osc commit breaks due to
the use of sfilelist.findall('.//entry[@hash]')
I now will iterate through the sfilelist and use
for entry in sfilelist.findall('entry'):
if entry.get('hash'):
... execute hash code ...
This is a little bit slower, but should not break
on SLE11 anymore
Without this change, using "--alternative-project <prj>" in combination
with "--multibuild-package <flavor>" yields to unexpected results (from
a user's point of view). Note that this may break existing (artificial)
workflows (e.g., using --alternative-project to ignore the package
meta's debuginfo flag), but these workflows should be rare and there
are options to achieve the same.
Fixes: #376 ("osc build -M something does not work with
--alternative-project")
Only include a tag if it "has" text in get_request_issues. Note
that the code in get_formatted_issues always assumes the presence
of the "label" tag.
Fixes: #369 ("crash trying to view diff of a request")
The retrun at this point breaks the call, because in most
cases <prj> is not a binary. And the code always checks for the
binary first and then returns if no binary with the name <prj>
is found.
The following abstract methods are added to the PackageQueryResult
class: recommends(), suggests(), supplements(), and enhances().
Note that not all package/metadata formats have a notion of these
weak dependencies.
rpm rpmmd deb arch
recommends x x x
suggests x x x x
supplements x x
enhances x x x
(where "x" represents "supported"). In case of an unsupported weak
dependency, the implementation returns an empty list.
We need the weak dependency support in order to fix#363 ("osc build
-p ../rpms/tw doesnt send recommends to the server which makes client
side build behave differently to server side build").
There is no good reason why "--revision <rev>" and "--expand-link" or
"--revision <rev>" and "--unexpand-link" should be mutually exclusive
during an "osc up" of a package wc.
Introduce the new "--linkrev <rev>" option to specify a rev of the link
target that is used during link expansion.
In case of a pulled/linkrepair wc, it is possible that the backend
requests a hash for a tracked file, which is neither added, restored,
nor modified. For instance, this can happen if a new file was added
to the link target. Hence, for a pulled/linkrepair wc always send
the sha256 hashes of the tracked files.
This is needed for a new validation of the source server.
The source server will 'ask' for the sha256 sum of files which are new or
modified and osc calculates the sha256 sums for those files and sends them
back to the server.
The server checks the sha256 sums and if dies if something is wrong.
Mount sysfs during "osc chroot". The current implementation
of "osc chroot" is a major pain for plain "su" users, because the
root password has to be entered several times - we should fix this.
Fixes: #354 ("Mount sysfs in chroot")
At the moment just repo.name is considered. So if
the repo is disabled for s390 all other repo / arch
combination are not shown in the repo list.
To be able to change this r is now a list of dicts
containing the name and arch of the disabled repo.
None for repo if a complete arch gets disabled
None for arch if a complete repo gets disabled
Store a newly created config file in $XDG_CONFIG_HOME/osc/. For backward
compatibility, ~/.oscrc is used, if present.
Fixes: #313 ("oscrc should be stored in $XDG_CONFIG_HOME on linux")
write oscrc to the default location for user-specific configuration.
If XDG_CONFIG_HOME is not set use ~/.config/osc/oscrc which is basically the same.
If there is already a ~/.oscrc use this one (for compat reasons). Existing user
installations should not get affected by this commit.
The order is the following:
Given config with -c
config defined in OSC_CONFIG
existing ~/.oscrc
default XDG_CONFIG_HOME/osc/oscrc
Support an xz compressed control.tar file. In case of a control.tar.xz and
a missing lzma module, an exception is thrown at runtime (for now, in order
to avoid a hard depedency to the lzma module, which is no standard module).
Similar to recent fixes in libsolv and obs-build. Since tarfile
on python2 doesn't do lzma, decompress the file into memory and
feed it as a fake file via StringIO to tarfile
Multiple context expressions are only supported since version 2.7.
It was introduced in commit f6f879d ("Fix potential shell injection
when running rpm2cpio").
Actually, there is nothing that can be injected, except the "-h"
option. However, in case rpm2cpio evolves, we are on the safe side.
Also, document the potential shell injection in the cpio call
(the comment was accidentally removed in commit dbdc712) (the
current osc code is not affected, because we never pass filenames
via *files to core.unpack_srcrpm).
It seems that the "find" binary has no way to indicate an
end of options for its arguments. Hence, we use os.walk to mimic
"find"'s behavior, which is also the cleaner solution.
Fixes: #340 ("osc add of directories does not quote the argument")
This basically reverts commit b2b59ca, because the old code performed
a "no" instead of a "yes" (see also the discussion in
https://github.com/openSUSE/osc/pull/269).
Fixes: #343 ("'osc sr --yes ...' doesn't supersede existing requests
as promised")
The old code was flawed, because, for instance,
core.show_results_meta(apiurl, project, arch=['x86_64']) resulted
in a wrong http request: GET <apiurl>/build/<project>/_result&arch=x86_64
(note the "&" instead of the correct "?"). The drawback of the new
implementation is that we have to do the proper quoting manually.
This harmonizes "osc prjresults --help" with osc's actual behavior.
Also, core.get_prj_results expects lists (or None) instead of strings
for the corresponding repo/arch parameters.
This is a follow-up commit for commit c9c0f8a. Using core.run_external
with shell=True is too error-prone.
Fixes: #340 ("osc add of directories does not quote the argument")
Also, document a potential shell injection in core.unpack_srcrpm
(via the "files" parameter), which cannot be exploited, because
"files" is not used by the current osc code.
Fixes: #340 ("osc add of directories does not quote the argument")
Provide function to show the content of rpmlint.log.
The core function get_rpmlint_log will later be used in the interactive
request mode to provide the rpmlint logs to the reviewer.
I add the osc rpmlint | rpmlintlog | lint command also.
