Script 'mail_helper' called by obssrc
Hello community,

here is the log from the commit of package tpm-tools for openSUSE:Factory 
checked in at 2021-10-05 22:33:59
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/tpm-tools (Old)
 and      /work/SRC/openSUSE:Factory/.tpm-tools.new.2443 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Package is "tpm-tools"

Tue Oct  5 22:33:59 2021 rev:34 rq:923211 version:1.3.9.2

Changes:
--------
--- /work/SRC/openSUSE:Factory/tpm-tools/tpm-tools.changes      2021-03-30 
21:18:55.365851360 +0200
+++ /work/SRC/openSUSE:Factory/.tpm-tools.new.2443/tpm-tools.changes    
2021-10-05 22:34:28.738934742 +0200
@@ -1,0 +2,8 @@
+Tue Oct  5 12:10:20 UTC 2021 - Matthias Gerstner <matthias.gerst...@suse.com>
+
+- fix undefined and binary data being output in the tpm_version command
+  (bsc#1114793)
+  - add 0001-tpm_version-avoid-outputting-NULL-bytes-from-tpmVend.patch
+  - add 0001-tpm_version-avoid-outputting-undefined-data-on-stder.patch
+
+-------------------------------------------------------------------

New:
----
  0001-tpm_version-avoid-outputting-NULL-bytes-from-tpmVend.patch
  0001-tpm_version-avoid-outputting-undefined-data-on-stder.patch

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Other differences:
------------------
++++++ tpm-tools.spec ++++++
--- /var/tmp/diff_new_pack.muSlc8/_old  2021-10-05 22:34:29.122935410 +0200
+++ /var/tmp/diff_new_pack.muSlc8/_new  2021-10-05 22:34:29.126935417 +0200
@@ -32,6 +32,10 @@
 BuildRequires:  openssl-devel
 BuildRequires:  trousers-devel
 BuildRoot:      %{_tmppath}/%{name}-%{version}-build
+# I reported this to the tpm-tools/trousers mailing list on 2018-12-03 but the
+# patches never made it into the upstream repo for some reason
+Patch0:         0001-tpm_version-avoid-outputting-NULL-bytes-from-tpmVend.patch
+Patch1:         0001-tpm_version-avoid-outputting-undefined-data-on-stder.patch
 
 %description
 Trusted Computing is a set of specifications published by the Trusted
@@ -89,7 +93,7 @@
 tpm-tools applications.
 
 %prep
-%setup -q -n %{name}-%{version}
+%autosetup -p1 -n %{name}-%{version}
 
 %build
 sh bootstrap.sh

++++++ 0001-tpm_version-avoid-outputting-NULL-bytes-from-tpmVend.patch ++++++
>From c927f67f36a4719bd15b8a535efb6980f1e87a6b Mon Sep 17 00:00:00 2001
From: Matthias Gerstner <matthias.gerst...@suse.de>
Date: Fri, 30 Nov 2018 12:48:37 +0100
Subject: [PATCH] tpm_version: avoid outputting NULL bytes from tpmVendorID

When the vendor ID contains null bytes then '^@' characters appear in
the tpm_version output. This can confuse users and it also causes e.g.
'grep' to treat the input as binary. Example:

  TPM Vendor ID:       WEC\000

This change copies the vendor ID bytes over into a local string object.
This makes the code more independent of the vendor ID dimension and also
avoids NULL bytes being printed.
---
 src/tpm_mgmt/tpm_version.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

Index: tpm-tools-1.3.9.1/src/tpm_mgmt/tpm_version.c
===================================================================
--- tpm-tools-1.3.9.1.orig/src/tpm_mgmt/tpm_version.c
+++ tpm-tools-1.3.9.1/src/tpm_mgmt/tpm_version.c
@@ -133,6 +133,7 @@ int cmdVersion(const char *a_szCmd)
                UINT64 offset;
                TSS_RESULT uiResult;
                TPM_CAP_VERSION_INFO versionInfo;
+               char vendor_id[sizeof(versionInfo.tpmVendorID)+1];
                char *errbuf = NULL; // Buffer containing what was sent to 
stderr during getCapability.
 
                /* Disable logging to of "Bad Mode" during this call. 
@@ -169,15 +170,17 @@ int cmdVersion(const char *a_szCmd)
                        goto out_close;
                }
 
+               // copy over the individual characters into a regular string.
+               // This avoids that null bytes are written to stdout.
+               snprintf ( vendor_id, sizeof(vendor_id), "%s", (const 
char*)versionInfo.tpmVendorID );
+
                logMsg(_("  TPM 1.2 Version Info:\n"));
                logMsg(_("  Chip Version:        %hhu.%hhu.%hhu.%hhu\n"),
                       versionInfo.version.major, versionInfo.version.minor,
                       versionInfo.version.revMajor, 
versionInfo.version.revMinor);
                logMsg(_("  Spec Level:          %hu\n"), 
versionInfo.specLevel);
                logMsg(_("  Errata Revision:     %hhu\n"), 
versionInfo.errataRev);
-               logMsg(_("  TPM Vendor ID:       %c%c%c%c\n"),
-                      versionInfo.tpmVendorID[0], versionInfo.tpmVendorID[1],
-                      versionInfo.tpmVendorID[2], versionInfo.tpmVendorID[3]);
+               logMsg(_("  TPM Vendor ID:       %s\n"), vendor_id);
 
                if (versionInfo.vendorSpecificSize) {
                        logMsg(_("  Vendor Specific data: "));
++++++ 0001-tpm_version-avoid-outputting-undefined-data-on-stder.patch ++++++
>From f0f30ff3e3b08751ebb8524303d80b6e94882134 Mon Sep 17 00:00:00 2001
From: Matthias Gerstner <matthias.gerst...@suse.de>
Date: Fri, 30 Nov 2018 13:17:01 +0100
Subject: [PATCH] tpm_version: avoid outputting undefined data on stderr

If there was no data written to the temporary file then memsize == 1, no
data will be read from the file into the buffer and the buffer will not
be null terminated. This can cause random data to be output later on to
the original stderr like:

'#precedence ::ffff:0:0/'

or

'xl?8?'

Fix this by making sure the buffer is always zero terminated.
---
 src/tpm_mgmt/tpm_version.c | 3 +++
 1 file changed, 3 insertions(+)

Index: tpm-tools-1.3.9.1/src/tpm_mgmt/tpm_version.c
===================================================================
--- tpm-tools-1.3.9.1.orig/src/tpm_mgmt/tpm_version.c
+++ tpm-tools-1.3.9.1/src/tpm_mgmt/tpm_version.c
@@ -99,6 +99,9 @@ char* end_capture_stderr(int olderr)
     perror("read()");
   }
 
+  // make sure the buffer is null terminated.
+  buf[st.st_size] = '\0';
+
   // Restore stderr.
  errout:
   if (0 > dup2(olderr, STDERR_FILENO)) {

Reply via email to