[Rpm-maint] [PATCH] Add support for 7zip compressed tarballs
Teach %prep and %uncompress how to handle 7zip tarballs, with
the mingw toolchain landing in fedora, this may be useful when
crossbuilding Windows sources compressed using 7zip (CxImage is
one such project).
---
build/parsePrep.c |4
configure.ac|1 +
macros.in |1 +
rpmio/macro.c |3 +++
rpmio/rpmfileutil.c |4
rpmio/rpmfileutil.h |3 ++-
6 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/build/parsePrep.c b/build/parsePrep.c
index 1efbcf2..fd4d30c 100644
--- a/build/parsePrep.c
+++ b/build/parsePrep.c
@@ -193,6 +193,10 @@ static char *doUntar(rpmSpec spec, uint32_t c, int quietly)
case COMPRESSED_LRZIP:
t = %{__lrzip} -dqo-;
break;
+ case COMPRESSED_7ZIP:
+ t = %{__7zip} x;
+ needtar = 0;
+ break;
}
zipper = rpmGetPath(t, NULL);
if (needtar) {
diff --git a/configure.ac b/configure.ac
index 4501b5c..622affe 100644
--- a/configure.ac
+++ b/configure.ac
@@ -91,6 +91,7 @@ fi
dnl
dnl Find some common programs
dnl
+AC_PATH_PROG(__7ZIP, 7zip, /usr/bin/7za, $MYPATH)
AC_PATH_PROG(__BZIP2, bzip2, /usr/bin/bzip2, $MYPATH)
AC_PATH_PROG(__CAT, cat, /bin/cat, $MYPATH)
AC_PATH_PROG(__CHGRP, chgrp, /bin/chgrp, $MYPATH)
diff --git a/macros.in b/macros.in
index b0b78aa..0bf0fa4 100644
--- a/macros.in
+++ b/macros.in
@@ -31,6 +31,7 @@
#==
# Generally useful path macros.
#
+%__7zip@__7ZIP@
%__awk @AWK@
%__bzip2 @__BZIP2@
%__cat @__CAT@
diff --git a/rpmio/macro.c b/rpmio/macro.c
index 238ebcd..e5a3463 100644
--- a/rpmio/macro.c
+++ b/rpmio/macro.c
@@ -971,6 +971,9 @@ doFoo(MacroBuf mb, int negate, const char * f, size_t fn,
case COMPRESSED_LRZIP:
sprintf(be, %%__lrzip -dqo- %s, b);
break;
+ case COMPRESSED_7ZIP:
+ sprintf(be, %%__7zip x %s, b);
+ break;
}
b = be;
} else if (STREQ(getenv, f, fn)) {
diff --git a/rpmio/rpmfileutil.c b/rpmio/rpmfileutil.c
index 7c229e6..bae9ab9 100644
--- a/rpmio/rpmfileutil.c
+++ b/rpmio/rpmfileutil.c
@@ -388,6 +388,10 @@ int rpmFileIsCompressed(const char * file,
rpmCompressedMagic * compressed)
((magic[0] == 0037) (magic[1] == 0235)) /* compress */
) {
*compressed = COMPRESSED_OTHER;
+} else if ((magic[0] == '7') (magic[1] == 'z')
+ (magic[2] == 0xbc) (magic[3] == 0xaf)
+ (magic[4] == 0x27) (magic[5] == 0x1c)) {
+ *compressed = COMPRESSED_7ZIP;
} else if (rpmFileHasSuffix(file, .lzma)) {
*compressed = COMPRESSED_LZMA;
}
diff --git a/rpmio/rpmfileutil.h b/rpmio/rpmfileutil.h
index 28c6d8a..52f8fba 100644
--- a/rpmio/rpmfileutil.h
+++ b/rpmio/rpmfileutil.h
@@ -25,7 +25,8 @@ typedef enum rpmCompressedMagic_e {
COMPRESSED_LZMA= 4,/*! lzma can handle */
COMPRESSED_XZ = 5,/*! xz can handle */
COMPRESSED_LZIP= 6,/*! lzip can handle */
-COMPRESSED_LRZIP = 7 /*! lrzip can handle */
+COMPRESSED_LRZIP = 7,/*! lrzip can handle */
+COMPRESSED_7ZIP= 8 /*! 7zip can handle */
} rpmCompressedMagic;
/** \ingroup rpmfileutil
--
1.7.10.1
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Tizen rpm security plug-in interface
Hi, I would like to give an update on the status of the rpm security plugin interface. I have moved the patch to the latest rpm code and will be upgrading it weekly form now on. I have fixed the issue that you commented last time with FSM hooks that were passing the fsm structure in full to the plug-in and now it passes only the needed information. Also, I have changed some parts related to the signature handling in the plug-in itself. The code is here in one commit (together with the plug-in code to illustrate the use of hooks): https://github.com/ereshetova/rpm/commit/5f4bb06a617fefceeb2656de3f11d9dd657 e352c I would really like to bring this code to shape now (since I have time right now) and would be very thankful for all the comments! Please don't pay attention to the cosmetics yet, only to the functionality since this is far from being a ready patch :) Could you also suggest who is currently maintaining (if any) the SElinux part in rpm? I would like to discuss if the current set of hooks is enough or smth needs modification. I also updated the wiki (https://github.com/ereshetova/rpm/wiki ) and made a separate page for the hooks description: https://github.com/ereshetova/rpm/wiki/Security-Hooks-for-rpm Best Regards, Elena. -Original Message- From: rpm-maint-boun...@lists.rpm.org [mailto:rpm-maint-boun...@lists.rpm.org] On Behalf Of Reshetova, Elena Sent: Tuesday, November 01, 2011 12:52 PM To: Panu Matilainen Cc: rpm-maint@lists.rpm.org; Ware, Ryan R Subject: Re: [Rpm-maint] Tizen rpm security plug-in interface Hi Panu, Thank you for the reply! Unfortunately from time to time I have to start my mails to some people with exactly same words, so I understand very well that you mean. I personally think that selinux needs aren't very much different than our needs and we can come up with a set of security hooks that should be enough for both. Do you know if selinux people or people who made selinux implementation for rpm will be willing to collaborate with us to help defining a sound set of hooks or to verify that set we will be defining is suitable for them? Now about answering your questions about the hooks. I have written a short summary of how hooks are used or reasoning behind them. I am also attaching the whole patch, where the hooks are implemented that you can look to the implementation of hooks themselves. __ +RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_INIT_FUNC); This is basic initialization function for the plug-in. +RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_FILE_CONFLICT_FUNC); The reason why this hook is needed is rather simple. Yes, rpm doesn't allow this by default, but since we enforce mandatory access control, then even if the user uses force option, we want to make sure that for example some important system executables or files can't be overwritten. The example of the attack it is guarding against is that user can try to install a package that overwrites sensitive system settings file that can allow him to circumvent security. This attack can be very typical for the attacker models, where user of the device isn't trusted enough to modify system settings or security policies. In msm this hook is used to make populate a hash list of file path conflicts with a new conflict information (like a path and sw source of the package that conflicts). Later, when package signature is verified and we are sure where the package comes from, the plug-in can make a decision whatever this package introduces a security conflict and installation must be aborted. +RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_PRE_TSM_FUNC); This hook isn't really used by msm apart that basic check is done on internal structure existence. However, I think the hook may be useful since other security plug-ins may want to include some checks before bunch of packages are installed. +RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_VERIFY_FUNC); The reason for this hook comes from the fact that plugin maintains what we call a device security policy that arranges known software sources in a form of a tree with different trust levels assigned. This is needed because gpg can't give us any order and we want to build a hierarchical tree of software sources and define the rules, if package from one source can overwrite a package from another. Based on this information, a lot of decisions are done, if package should be installed or not and if applications from this package are allowed to request certain types of accesses on the platform. So, in this hook, msm plug-in simply maps the package to one of its internal software sources and does an additional verification of the key fingerprint. It is currently stored in device security policy too, but I think this part can be removed from plug-in later when proper certificate manager is used to secure code signing certificates. Does this explain a bit better the need of this hook? I also have things written that explain what
