Hello,
On Monday, August 3, 2020 6:50:49 PM EDT Guillem Jover wrote:
 We got a request to add audit support to dpkg [R], and as initially
 mentioned on the bug report it seems the AUDIT_SOFTWARE_UPDATE format
 does not appear to be documented, so while looking into all this, got
 several questions.
 
   [R] <
https://bugs.debian.org/931748>
 
 >From the rpm implementation and auparse/normalize.c I gather that it
 would contain the following fields, applied to dpkg:
 
   * primary field would be "sw" which would contain something like
     «"nginx_1.18.0-5_amd64"», I assume that the format differing from
     the one in rpm is fine as that would be keyed on the next field? 
sure
   * secondary field would be "sw_type" which would be
«dpkg». 
yes
   * field "op", which would contain entries different to
rpm, such as
     «unpack», «configure», «install», «remove», «purge», not sure if
     that might be a problem? 
From compliance perspective, only install, update, and remove are
relevant.  
You want to know when something gets added or removed because they could
add 
setuid programs or daemons that autostart. Secondly, you may be tracking 
current versions to resolve CVE's. So, for that purpose, you also want to 
know when something gets updated. Nothing else matters.
How does unpack differ from install? How does purge differ from remove? There 
is another event type, AUDIT_USYS_CONFIG, that tracks user space configuration 
changes. However, this is rarely used. Instead, what is done is watches are 
placed on important configuration files to see if anything opens the file for 
modiciation. So, would there be any need to have a configuration option for 
SOFTWARE_UPDATE?
   * field "key_enforce", I take to denote whether a
cryptographic
     verification has been performed on the .deb archive? With values
     «0» or «1». (This would depend on whether debsig-verify(1) has
     been configured to be executed or not.) 
This denotes whether signature checks is being enforced. This is independent 
from whether or not the signature is valid. IOW, if a signature (next field) 
is invalid, will the package be allowed in anyway?
   * field "gpg_res", to denote whether the aforementioned
verification
     succeeded or not? With values «0» or «1». And while dpkg can indeed
     use GnuPG to verify signatures from archives, the name feels too
     implementation specific, perhaps it could be renamed so that it
     would not be very confusing, in case someone implements a check
     based on say x509 certificates? 
This field is whether or not the package passes its verification with a hash, 
gpg signature, x509 certificate, or any other integrity scheme.
   * field "root_dir", to denote the installation root
directory, which
     would map to dpkg --instdir value, with a value such as «"/"». 
Yes. Rpms can be relocatable to anywhere. So, this is to document what part 
of the system the package will affect.
 Anything else I might have missed or might be worth taking into
 account while adding the support? 
I think that's pretty much  it. If you wanted to see an example of the code, 
it is here:
https://github.com/rpm-software-management/rpm/blob/master/plugins/
audit.c#L80
-Steve