Bug#985158: [pkg-gnupg-maint] Bug#985158: Bug#985158: Bug#985158: Bug#985158: gpg: No longer reads .gnupg/options

2021-03-15 Thread Andre Heinecke
Hi,

On Monday 15 March 2021 08:56:36 CET Christoph Biedl wrote:
> > > Point is, the legacy file ~/.gnupg/options is still being used in
> > > surprisingly many applications, also in documentation:

Sorry, but  a quick look at the codesearch you linked shows it is not used 
anywhere except in some outdated documentation or syntax highlighting. Even 
https://sources.debian.org/src/samhain/4.1.4-2/scripts/samhainadmin.pl.in/?
hl=66#L66 which looked from the codesearch as the most promising candidate 
uses gpg.conf preferredly.

> For *after* the release, everything will be possible. My intent is to
> keep impact for the current release low.

I am using GnuPG since 2006 and I was not even aware that .gnupg/options was a 
thing before this thread.

> My preferred solution was to restore the old behaviour for a limited
> time, i.e. parsing the legacy config file, plus emitting that warning.
> This will give everybody a chance to adjust their configuration.

I think this is an overraction. I cannot imagine that more then a handful of 
users are affected by this change of ignoring such an historic file. Also those 
are options, this is nothing security critical in my opinion. Options and 
option defaults change regularly from one debian release the next.

Best Regards,
Andre 


-- 
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 Düsseldorf.  VR 11482 Düsseldorf
Vorstand: W.Koch, B.Reiter, A.HeineckeMail: bo...@gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-211-28010702

signature.asc
Description: This is a digitally signed message part.


Bug#925952: libkf5libkleo5: Kleopatra archive command has wrong syntax for buster's tar

2019-03-29 Thread Andre Heinecke
Package: libkf5libkleo5
Version: 4:18.08.3-2
Severity: normal

Dear Maintainer,

Kleopatra used a slightly wrong syntax for calling tar when archiving
a folder. This is no longer accepted by tar and leads to errors.

This was fixed upstream by:
https://cgit.kde.org/libkleo.git/commit/?
id=8a94ac0835f0cff8908943d2a630a003a3429220


The upstream report for this is:
https://dev.gnupg.org/T4442

Please consider adding that patch as otherwise archiving (encrypting a folder)
no longer works in Kleopatra.

Thanks and best Regards,
Andre

-- 
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 Düsseldorf.  VR 11482 Düsseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke.Mail: bo...@gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-2104-4938799

signature.asc
Description: This is a digitally signed message part.


Bug#923214: g++-mingw-w64: Internal compiler error when include qfloat16.h, Qt5.12.

2019-03-05 Thread Andre Heinecke
Hi,

I was affected by this, too when compiling Gpg4win. Caused an error in Boost 
and the mentioned Qt error.

I want to thank you very much for investigating and causing this bug to be 
fixed. I've compiled myself packages with the fix from https://gcc.gnu.org/
bugzilla/show_bug.cgi?id=88568  (diff attached)

With this fix I was able to fully compile Gpg4win again (which includes a ton 
of packages like gtk+, qt, boost, kde-frameworks, etc..).

Best Regards,
Andre

-- 
GnuPG e.V., Rochusstr. 44, D-40479 Düsseldorf.  VR 11482 Düsseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke.Mail: bo...@gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-2104-4938799>From 2ddbe8e4d39d145b2aa0356c9ff6835bda73abf5 Mon Sep 17 00:00:00 2001
From: Andre Heinecke 
Date: Tue, 5 Mar 2019 18:35:12 +0100
Subject: [PATCH] Fix gcc bug-88568

---
 debian/changelog   |  6 +
 debian/patches/bug-88568.patch | 40 ++
 debian/patches/series2 |  1 +
 3 files changed, 47 insertions(+)
 create mode 100644 debian/patches/bug-88568.patch

diff --git a/debian/changelog b/debian/changelog
index d9b3631..f72efab 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+gcc-mingw-w64 (21.2~aheinecke1) unstable; urgency=medium
+
+  * Add patch for g++ bug 88568 (closes: #923214)
+
+ -- Andre Heinecke   Tue, 05 Mar 2019 16:21:03 +0100
+
 gcc-mingw-w64 (21.1) unstable; urgency=medium
 
   * Avoid attempting to strip plugins using the target strip; should fix
diff --git a/debian/patches/bug-88568.patch b/debian/patches/bug-88568.patch
new file mode 100644
index 000..dbc76df
--- /dev/null
+++ b/debian/patches/bug-88568.patch
@@ -0,0 +1,40 @@
+2019-03-05  Jakub Jelinek  
+
+	PR c/88568
+	* attribs.c (handle_dll_attribute): Don't clear TREE_STATIC for
+	dllimport on VAR_DECLs with RECORD_TYPE or UNION_TYPE DECL_CONTEXT.
+
+	* g++.dg/other/pr88568.C: New test.
+
+--- gcc-mingw-w64.orig/src/gcc/attribs.c.jj	2019-01-10 11:44:07.122511397 +0100
 gcc-mingw-w64/src/gcc/attribs.c	2019-03-05 13:59:51.745924578 +0100
+@@ -1691,8 +1691,11 @@ handle_dll_attribute (tree * pnode, tree
+ 	 a function global scope, unless declared static.  */
+ 	  if (current_function_decl != NULL_TREE && !TREE_STATIC (node))
+ 	TREE_PUBLIC (node) = 1;
+-	  /* Clear TREE_STATIC because DECL_EXTERNAL is set.  */
+-	  TREE_STATIC (node) = 0;
++	  /* Clear TREE_STATIC because DECL_EXTERNAL is set, unless
++	 it is a C++ static data member.  */
++	  if (DECL_CONTEXT (node) == NULL_TREE
++	  || !RECORD_OR_UNION_TYPE_P (DECL_CONTEXT (node)))
++	TREE_STATIC (node) = 0;
+ 	}
+ 
+   if (*no_add_attrs == false)
+--- gcc-mingw-w64.orig/src/gcc/testsuite/g++.dg/other/pr88568.C.jj	2019-03-05 14:03:20.132509560 +0100
 gcc-mingw-w64/src/gcc/testsuite/g++.dg/other/pr88568.C	2019-03-05 14:01:39.674155860 +0100
+@@ -0,0 +1,13 @@
++// PR c/88568
++// { dg-do compile }
++// { dg-require-dll "" }
++
++struct S {
++  __attribute__((dllimport)) static const char foo[];
++};
++
++int
++foo (int x)
++{
++  return S::foo[x];
++}
diff --git a/debian/patches/series2 b/debian/patches/series2
index 6f5002f..e6543c6 100644
--- a/debian/patches/series2
+++ b/debian/patches/series2
@@ -8,3 +8,4 @@ filesystem_error-no-throw-copyable.patch
 overload-distance-and-advance.patch
 #update-path-compare-logic.patch
 #fix-filesystem-path-lexically_normal.patch
+bug-88568.patch
-- 
2.20.1



signature.asc
Description: This is a digitally signed message part.


Bug#869647: kleopatra: Missing dependency to libkf5libkleo-data

2017-07-25 Thread Andre Heinecke
Package: kleopatra
Version: 4:16.04.2-2+b2
Severity: important

Dear Maintainer,

This is a downstream report of a bug reported in the kde bugtracker.

https://bugs.kde.org/show_bug.cgi?id=380490

Kleopatra needs the libkleopatrarc which is part of libkf5libkleo-data
otherwise several features won't work and may have unexpected behavior.

Please add the dependency.

Thanks and best regards,
Andre

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kleopatra depends on:
ii  libassuan0  2.4.3-2
ii  libc6   2.24-11+deb9u1
ii  libgcc1 1:6.3.0-18
ii  libgpg-error0   1.26-2
ii  libgpgme11  1.8.0-3+b2
ii  libkf5configcore5   5.28.0-2
ii  libkf5configgui55.28.0-2
ii  libkf5configwidgets55.28.0-2
ii  libkf5coreaddons5   5.28.0-2
ii  libkf5dbusaddons5   5.28.0-1
ii  libkf5gpgmepp-pthread5  16.04.3-2+b2
ii  libkf5i18n5 5.28.0-2
ii  libkf5iconthemes5   5.28.0-2
ii  libkf5kcmutils5 5.28.0-2
ii  libkf5libkleo5  4:16.04.2-1
ii  libkf5mime5 16.04.2-1
ii  libkf5notifications55.28.0-1
ii  libkf5textwidgets5  5.28.0-1
ii  libkf5widgetsaddons55.28.0-3
ii  libkf5windowsystem5 5.28.0-2
ii  libkf5xmlgui5   5.28.0-1
ii  libqt5core5a5.7.1+dfsg-3+b1
ii  libqt5dbus5 5.7.1+dfsg-3+b1
ii  libqt5gui5  5.7.1+dfsg-3+b1
ii  libqt5network5  5.7.1+dfsg-3+b1
ii  libqt5widgets5  5.7.1+dfsg-3+b1
ii  libstdc++6  6.3.0-18

kleopatra recommends no packages.

kleopatra suggests no packages.

-- no debconf information



Bug#840642: gpgme binding cleanup

2016-10-13 Thread Andre Heinecke
On Wednesday 12 October 2016 20:34:25 Daniel Kahn Gillmor wrote:
> However, we also have several remaining copies of GPGME bindings in
> debian, and it would be good to reduce their number.  This will save the
> sanity of our users; will provide better focus for upstream developers;
> and will be easier for us to maintain going forward.
> 
> In debian, we have:
> 
>  * src:kdepimlibs, which builds several binary packages, including:
>- libgpgme++2v5
>- libqgpgme1
> 
>We should be able to drop these two binary packages from the build of
>src:kdepimlibs; packages linking against these tools should be able
>to rebuild against libgpgmepp6 and libqgpgme6.  This means that any
>build-dependencies should probably move to libgpgmepp-dev instead of
>kdepimlibs5-dev

For libqgpgme rebuilding kdepimlibs depending packages wont't work because 
kdepimlibs qgpgme was Qt4 and libqgpgme from the gpgme package is Qt5. You 
can't link Qt4 and Qt5 together.

For gpgmepp It would require changing how the library is found. And depending 
on the used API this will not work as gpgmepp from the gpgme package slightly 
broke API to use C++11 memory instead of Boost (so that it is now plain c++ 
without external dependencies) and some deprecated API was removed.

But that affected mainly esoteric API regarding Assuan interaction.
Additionally you now need C++11 which kdepimlibs did not.
 
>  * src:gpgmepp, which builds several binary packages, including
>- libkf5gpgmepp5
>- libkf5qgpgme5
> 
>We should be able to drop this entire source package from the
>archive.  Any build dependencies should probably move to
>libgpgmepp-dev from libkf5gpgmepp-dev.

Yes. But as the libraries are coinstallable keeping around the current Version 
probably won't hurt. As said above there was a slight API break.

> Turns up the following packages that might need to be rebuilt:
> 
>   kaddressbook
>   kde-runtime
>   kget
>   kmymoney
>   libkf5libkleo5
>   libkf5wallet-bin
>   libkleo4
>   libkwalletbackend5-5
>   libmessagecomposer4
>   libmessageviewer4

This list looks incomplete to me (probably implicity dependencies?). At least 
Kleopatra is missing or are you not shipping a kde4 based kleopatra anymore? 
(In that case I wonder why kaddressbook is in there)

> One thing i note is that we have libkleo4 and libkleo5.  I don't know
> how tightly-bound kde4 is with qt4, 

Complete tightness. :-) You can't link qt4 and 5 together.

> but it maybe we want a separate
> binary package of libqgpgme that is built against qt4 instead of qt5.
> I can look into providing that as a separate build in gpgme if that
> would be useful.

In kdepimlibs (qt4) qgpgme was very small, just two (very useful) classes, 
maybe we could provide the kdepimlibs qgpgme offererd when built agains Qt4 but 
I doubt the usefullness.

Completly converting qgpgme (from gpgme, which included a lot of API from 
libkleo) to Qt4 is not something I'd like to see as it uses nice features of 
Qt5.

> Let me know what you think the next steps should be in proceeding with
> this cleanup.  (or if you think we should abandon the whole thing!)

I don't think you can get rid of the packages from kdepimlibs. So the cleanup 
would be only phasing out libkf5gpgmepp5 and libkf5qgpgme5 which should happen 
of course.

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

signature.asc
Description: This is a digitally signed message part.


Bug#806036: Privilege escalation and code execution vulnerabilities in generated NSIS installers

2015-12-02 Thread Andre Heinecke
Hi,

On Tuesday 01 December 2015 19:44:36 you wrote:
> I would propose to wait for the review and the fix going in upstream.
> Thereafter the fix could be back ported to the NSIS version distributed
> by Debian.

I agree. NSIS upstream reacted quickly and while it is of no concern to us (at 
gpg4win) I guess for Debian it could be problematic to ship a Version that is 
not compatible with all the Windows Versions NSIS is compatible with (versions 
before Windows XP).

We've published the patched packages we used for our last Installer package 
under http://apt.intevation.de for both wheezy and jessie.

( deb http://apt.intevation.de jessie nsis )

Btw. we've also published a security advisory about this problem in relation 
to Gpg4win. https://gpg4win.de/news-20151125.html


Thanks for your work on the Debian NSIS package.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner



Bug#806036: Privilege escalation and code execution vulnerabilities in generated NSIS installers

2015-11-24 Thread Andre Heinecke
Package: nsis
Version: 2.46-10

Installers generated by NSIS 2.46 are vulnerable to attacks that can lead to 
code execution and privilege escalation (if the installer is running with 
elevated privileges).

This has been reported to us at Gpg4win (www.gpg4win.org) which is built under 
Debian GNU/Linux. We saw no other option to mitigate the attacks then to patch 
our version of NSIS.

We've also reported this upstream today:
https://sourceforge.net/p/nsis/bugs/1125/

Background: Windows loads Libraries that are not "Known DLL's" from the 
directory of the executable first. As NSIS uses direct loading though 
LoadLibrary / LoadLibraryEx system calls, and links a not "Well Known" library 
(version.dll) placing Libraries with standard names like shfolder.dll or 
version.dll in the same Folder as an NSIS Installer (usually the Downloads 
folder) will load those libraries in the context of the installer. An attacker 
could cause these Libraries to be executed in the context of the installer.

This is especially problematic for signed Installers and Installers that 
require Elevated (Administrator) Privileges for installation. As this bypasses 
the signature validation and can be used for a privilege escalation.

Additionally NSIS uses an insecure temporary directory that can be modified 
with normal User access rights in case of an elevated installation. This can 
be used to modify plugins in that directory which then will be loaded with 
higher privileges. There is also a temporary file race on uninstallation where 
the uninstaller is copied into a temporary directory and afterwards executed 
with elevated privileges.

More details and descriptions about how we mitigate these attacks are 
available in the NSIS bug report.

Attached are the patches we are planning to use with NSIS to prepare our
next gpg4win release. They can be applied in the Order of their names to the 
debian version of NSIS and compile on wheezy and jessie.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner--- a/Source/exehead/util.c
+++ b/Source/exehead/util.c
@@ -942,12 +942,54 @@
   {"SHFOLDER", "SHGetFolderPathA"}
 };
 
+#ifndef LOAD_LIBRARY_SEARCH_SYSTEM32
+#define LOAD_LIBRARY_SEARCH_SYSTEM32 0x0800
+#endif
+
+#ifndef LOAD_LIBRARY_SEARCH_USER_DIRS
+#define LOAD_LIBRARY_SEARCH_USER_DIRS 0x0400
+#endif
+
+// Check if the system supports LoadLibraryEx flags to
+// restrict the search order. This migitates current
+// directory attacks.
+void NSISCALL RestrictLibrarySearch()
+{
+  typedef BOOL (WINAPI *sddd_t)(DWORD DirectoryFlags);
+  sddd_t sddd;
+  HMODULE hModule = GetModuleHandle("KERNEL32");
+  if (!hModule)
+  {
+/* KERNEL32.dll is one of the few Known libraries
+   on Windows so this is safe to do */
+hModule = LoadLibrary("KERNEL32");
+  }
+
+  sddd = (sddd_t) GetProcAddress (hModule, "SetDefaultDllDirectories");
+
+  if (!sddd)
+  {
+// SetDefaultDllDirectories not found this means we are either
+// on an unmaintained Windows or on a windows that does
+// not have KB2533623 installed.
+log_printf("SetDefaultDllDirectories failed.");
+return;
+  }
+
+  /* Users may use AddDllDirectory (SEARCH_USER_DIRS) but otherwise
+ we only load from System32. No installer should depend on the
+ insecure behavior of loading libraries from the directory in which
+ the installer is placed. This prevents DLL search order attacks
+ (CAPEC-471) against the current directory. */
+  sddd(LOAD_LIBRARY_SEARCH_USER_DIRS | LOAD_LIBRARY_SEARCH_SYSTEM32);
+}
+
 void * NSISCALL myGetProcAddress(const enum myGetProcAddressFunctions func)
 {
   const char *dll = MGA_FUNCS[func].dll;
   HMODULE hModule = GetModuleHandle(dll);
   if (!hModule)
-hModule = LoadLibrary(dll);
+hModule = LoadLibraryEx(dll, NULL, 0);
   if (!hModule)
 return NULL;
 
--- a/Source/exehead/util.h
+++ b/Source/exehead/util.h
@@ -117,6 +118,10 @@
 void * NSISCALL myGetProcAddress(const enum myGetProcAddressFunctions func);
 void NSISCALL MessageLoop(UINT uCheckedMsg);
 
+// Restrict the LoadLibraryEx library search folder to mitigate current
+// directory attacks.
+void NSISCALL RestrictLibrarySearch();
+
 // Turn a pair of chars into a word
 // Turn four chars into a dword
 #ifdef __BIG_ENDIAN__ // Not very likely, but, still...
--- a/Contrib/System/Source/System.c
+++ b/Contrib/System/Source/System.c
@@ -703,7 +703,7 @@
 {
 // Get DLL address
 if ((proc->Dll = GetModuleHandle(proc->DllName)) == NULL)
-if ((proc->Dll = LoadLibrary(proc->DllName)) == NULL)
+if ((proc->Dll = LoadLibraryEx(proc->DllName, NULL, 0)) == NULL)
 {
 

Bug#412993: gnupg-agent: Xsession.d/90gpg-agent should start agent unconditionally

2012-01-26 Thread Andre Heinecke
regardless of alternatives that are available:

- Current gnupg Versions rely on gpg-agent,
- gpg-agent should be started as a daemon or otherwise it does not need to be 
installed at all.
- The configuration option that debian relies on is deprecated.
- A user of Kleopatra for example without knowledge of the inner workings of 
gnupg is baffled why Kleopatra can't communicate with gpg-agent and would 
need to manually edit a configuration file with no direct connection to 
autostarting the daemon.

If debian thinks gpg-agent should be optional then gnupg2 should not depend on 
gnupg-agent but suggest it or gnome-keyring or something but the fact is that 
if you install the gnupg2 package you want to get a working gnupg setup and 
this includes an autostarted gpg-agent.

-- 
Andre Heinecke |  ++49-541-335083-262 |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org