rebuilt with debug package and aarch64 build fix [release 1.0.2-2mamba;Thu Dec 10 2020]

This commit is contained in:
Silvan Calarco 2024-01-05 19:42:32 +01:00
parent 99d1476225
commit 88083f8755
2 changed files with 9 additions and 29 deletions

View File

@ -4,17 +4,3 @@ The X firewall proxy (xfwp) is an application layer gateway proxy that may be ru
Used in conjunction with the X server Security extension and authorization checking, xfwp constitutes a safe, simple, and reliable mechanism both to hide the addresses of X servers located on the Intranet and to enforce a server connection policy. Used in conjunction with the X server Security extension and authorization checking, xfwp constitutes a safe, simple, and reliable mechanism both to hide the addresses of X servers located on the Intranet and to enforce a server connection policy.
Xfwp cannot protect against mischief originating on the Intranet; however, when properly configured it can guarantee that only trusted clients originating on authorized external Internet hosts will be allowed inbound access to local X servers. Xfwp cannot protect against mischief originating on the Intranet; however, when properly configured it can guarantee that only trusted clients originating on authorized external Internet hosts will be allowed inbound access to local X servers.
To use xfwp there must be an X proxy manager running in the local environment which has been configured at start-up to know the location of the xfwp.
[NOTE: There may be more than one xfwp running in a local environment; see notes below on load balancing for further discussion.]
Using the xfindproxy utility (which relays its requests through the proxy manager) a user asks xfwp to allocate a client listen port for a particular X server, which is internally associated with all future connection requests for that server.
This client listen port address is returned by the proxy manager through xfindproxy.
The xfwp hostname and port number is then passed out-of-band (i.e., via a Web browser) to some remote X client, which will subsequently connect to xfwp instead of to the target X server.
When an X client connection request appears on one of xfwp's listen ports, xfwp connects to the X server associated with this listen port and performs authorization checks against the server as well as against its own configurable access control list for requesting clients.
If these checks fail, or if the requested server does not support the X Security Extension, the client connection is refused.
Otherwise, the connection is accepted and all ensuing data between client and server is relayed by xfwp until the client terminates the connection or, in the case of an inactive client, until a configured timeout period is exceeded.
Xfwp is designed to block while waiting for activity on its connections, thereby minimizing demand for system cycles.
If xfwp is run without a configuration file and thus no sitepolicy is defined, if xfwp is using an X server where xhost + has been run to turn off host-based authorization checks, when a client tries to connect to this X server via xfwp, the X server will deny the connection.
If xfwp does not define a sitepolicy, host-based authorization must be turned on for clients to connect to an X server via the xfwp.

View File

@ -1,6 +1,6 @@
Name: xfwp Name: xfwp
Version: 1.0.2 Version: 1.0.2
Release: 1mamba Release: 2mamba
Summary: xfwp - X firewall proxy Summary: xfwp - X firewall proxy
Group: Graphical Desktop/Applications/Utilities Group: Graphical Desktop/Applications/Utilities
Vendor: openmamba Vendor: openmamba
@ -13,6 +13,7 @@ License: MIT
BuildRequires: glibc-devel BuildRequires: glibc-devel
BuildRequires: libICE-devel BuildRequires: libICE-devel
## AUTOBUILDREQ-END ## AUTOBUILDREQ-END
BuildRequires: xproxymanagementprotocol-devel
BuildRoot: %{_tmppath}/%{name}-%{version}-root BuildRoot: %{_tmppath}/%{name}-%{version}-root
%description %description
@ -20,22 +21,11 @@ The X firewall proxy (xfwp) is an application layer gateway proxy that may be ru
Used in conjunction with the X server Security extension and authorization checking, xfwp constitutes a safe, simple, and reliable mechanism both to hide the addresses of X servers located on the Intranet and to enforce a server connection policy. Used in conjunction with the X server Security extension and authorization checking, xfwp constitutes a safe, simple, and reliable mechanism both to hide the addresses of X servers located on the Intranet and to enforce a server connection policy.
Xfwp cannot protect against mischief originating on the Intranet; however, when properly configured it can guarantee that only trusted clients originating on authorized external Internet hosts will be allowed inbound access to local X servers. Xfwp cannot protect against mischief originating on the Intranet; however, when properly configured it can guarantee that only trusted clients originating on authorized external Internet hosts will be allowed inbound access to local X servers.
To use xfwp there must be an X proxy manager running in the local environment which has been configured at start-up to know the location of the xfwp. %debug_package
[NOTE: There may be more than one xfwp running in a local environment; see notes below on load balancing for further discussion.]
Using the xfindproxy utility (which relays its requests through the proxy manager) a user asks xfwp to allocate a client listen port for a particular X server, which is internally associated with all future connection requests for that server.
This client listen port address is returned by the proxy manager through xfindproxy.
The xfwp hostname and port number is then passed out-of-band (i.e., via a Web browser) to some remote X client, which will subsequently connect to xfwp instead of to the target X server.
When an X client connection request appears on one of xfwp's listen ports, xfwp connects to the X server associated with this listen port and performs authorization checks against the server as well as against its own configurable access control list for requesting clients.
If these checks fail, or if the requested server does not support the X Security Extension, the client connection is refused.
Otherwise, the connection is accepted and all ensuing data between client and server is relayed by xfwp until the client terminates the connection or, in the case of an inactive client, until a configured timeout period is exceeded.
Xfwp is designed to block while waiting for activity on its connections, thereby minimizing demand for system cycles.
If xfwp is run without a configuration file and thus no sitepolicy is defined, if xfwp is using an X server where xhost + has been run to turn off host-based authorization checks, when a client tries to connect to this X server via xfwp, the X server will deny the connection.
If xfwp does not define a sitepolicy, host-based authorization must be turned on for clients to connect to an X server via the xfwp.
%prep %prep
%setup -q %setup -q
sed -i "s,| arm-\* |,| aarch64-\* | arm-\* |," config.sub
%build %build
%configure %configure
@ -52,8 +42,12 @@ If xfwp does not define a sitepolicy, host-based authorization must be turned on
%defattr(-,root,root) %defattr(-,root,root)
%{_bindir}/%{name} %{_bindir}/%{name}
%{_mandir}/man?/* %{_mandir}/man?/*
%doc COPYING ChangeLog README %doc COPYING
#ChangeLog README
%changelog %changelog
* Thu Dec 10 2020 Silvan Calarco <silvan.calarco@mambasoft.it> 1.0.2-2mamba
- rebuilt with debug package and aarch64 build fix
* Tue Apr 26 2011 Tiziana Ferro <tiziana.ferro@email.it> 1.0.2-1mamba * Tue Apr 26 2011 Tiziana Ferro <tiziana.ferro@email.it> 1.0.2-1mamba
- package created by autospec - package created by autospec