Open predators46 opened 2 months ago
Thanks for this @predators46
putpwent()
is an interesting one. It's not in POSIX, and I can't find where it actually comes from.
Regarding your problem, I don't believe the function calling putpwent()
is currently used. Can you try this patch against v0.9.25.1? That should let us find any other compile issues at least.
--- a/sesman/verify_user.c
+++ b/sesman/verify_user.c
@@ -42,8 +42,10 @@
#define SECS_PER_DAY (24L*3600L)
#endif
+#if 0
static int
auth_crypt_pwd(const char *pwd, const char *pln, char *crp);
+#endif
static int
auth_account_disabled(struct spwd *stp);
@@ -184,6 +186,7 @@ auth_check_pwd_chg(const char *user)
return AUTH_PWD_CHG_OK;
}
+#if 0
int
auth_change_pwd(const char *user, const char *newpwd)
{
@@ -292,6 +295,7 @@ auth_crypt_pwd(const char *pwd, const char *pln, char *crp)
return 0;
}
+#endif
/**
*
@matt335672
there is another problem if doing cross compilation I don't find CC_FOR_BUILD in configure. keygen must cross-compile.
Thanks for this @predators46
putpwent()
is an interesting one. It's not in POSIX, and I can't find where it actually comes from.Regarding your problem, I don't believe the function calling
putpwent()
is currently used. Can you try this patch against v0.9.25.1? That should let us find any other compile issues at least.--- a/sesman/verify_user.c +++ b/sesman/verify_user.c @@ -42,8 +42,10 @@ #define SECS_PER_DAY (24L*3600L) #endif +#if 0 static int auth_crypt_pwd(const char *pwd, const char *pln, char *crp); +#endif static int auth_account_disabled(struct spwd *stp); @@ -184,6 +186,7 @@ auth_check_pwd_chg(const char *user) return AUTH_PWD_CHG_OK; } +#if 0 int auth_change_pwd(const char *user, const char *newpwd) { @@ -292,6 +295,7 @@ auth_crypt_pwd(const char *pwd, const char *pln, char *crp) return 0; } +#endif /** *
alpine has patches
Upstream: Not applicable but they are doing it wrong
Reason: Upstream is enabling Werror for non-debug builds
diff --git a/configure.ac b/configure.ac
index 8a2d230..7c9fdc2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -156,8 +156,6 @@ AX_TYPE_SOCKLEN_T
AX_CFLAGS_WARN_ALL
AX_APPEND_COMPILE_FLAGS([-Wwrite-strings])
-AM_COND_IF([LINUX],
- [AX_APPEND_COMPILE_FLAGS([-Werror])]) # bsd has warnings that have not been fixed yet
AM_COND_IF([XRDP_DEBUG],
[AX_APPEND_COMPILE_FLAGS([-g -O0])],
xrdp-keygen
is a tricky one.
It's used by make install
, but also needs to be available on the target system itself.
I'm wondering if a way round this is to ignore fails if xrdp-keygen during install, but to run it when the xrdp service is started if the file doesn't exist.
Presumably you're having to write a service script for OpenWRT to handle xrdp?
This patch should let the build run through without an rsakeys.ini being generated:-
--- a/keygen/Makefile.am
+++ b/keygen/Makefile.am
@@ -20,7 +20,7 @@ xrdpsysconfdir = $(sysconfdir)/xrdp
install-data-hook:
umask 077 && \
if [ ! -f $(DESTDIR)$(xrdpsysconfdir)/rsakeys.ini ]; then \
- ./xrdp-keygen xrdp $(DESTDIR)$(xrdpsysconfdir)/rsakeys.ini; \
+ ./xrdp-keygen xrdp $(DESTDIR)$(xrdpsysconfdir)/rsakeys.ini || : ; \
fi && \
if [ ! -f $(DESTDIR)$(xrdpsysconfdir)/cert.pem ]; then \
$(OPENSSL) req -x509 -newkey rsa:2048 -sha256 -nodes \
@matt335672
thank you I understand now
Let me know how you get on - this definitely falls into the 'interesting' category of PRs!
We might want to add a way to disable the compile-time generation of rsakeys.ini
and the TLS files. These are only useful if you're running make install
on the local machine. They're pointless if you're building a package as they need to be regenerated for each machine that the package is installed on.
Let me know how you get on - this definitely falls into the 'interesting' category of PRs!
We might want to add a way to disable the compile-time generation of
rsakeys.ini
and the TLS files. These are only useful if you're runningmake install
on the local machine. They're pointless if you're building a package as they need to be regenerated for each machine that the package is installed on.
in openwrt to cross compile you have to build the host first.
i can cross compile but xrdp needs openssl host while building xrdp as host but OpenWrt doesn't add host package in openssl
so for the time being, I created rsakeys.ini on my local machine.
is there a way to disable openssl in xrdp while building? i can cross compile if xrdp doesn't need openssl
currently I managed to build xrdp without rsakeys.ini when building xrdp.
I think that openssl is only used on make install
. Is that what you are seeing?
I think that openssl is only used on
make install
. Is that what you are seeing?
I see openssl is required when building xrdp
Yes - the libraries are. You'll need those in your build environment.
We've looked into using other ssl libraries when all the fuss started over openssl maintenance, but in the end we didn't implement any changes apart from the migration to the EVP interface for OpenSSL 3.0.
@matt335672
maybe add --disable-openssl
We need some sort of SSL library to provide RDP over TLS which is pretty mandatory these days.
Is there anything that works better for you than openSSL in your environment?
We need some sort of SSL library to provide RDP over TLS which is pretty mandatory these days.
Is there anything that works better for you than openSSL in your environment?
I haven't tried again. i don't have access to my virtual machine on linode
xrdp version
0.9.25.1
Detailed xrdp version, build options
Operating system & version
OpenWrt aarch64
Installation method
other
Which backend do you use?
No response
What desktop environment do you use?
OpenWrt
Environment xrdp running on
No response
What's your client?
No response
Area(s) with issue?
Other
Steps to reproduce
✔️ Expected Behavior
No response
❌ Actual Behavior
2024-05-06T23:00:39.0737006Z verify_user.c:221:9: error: implicit declaration of function 'putpwent'; did you mean 'getpwent'? [-Werror=implicit-function-declaration] 2024-05-06T23:00:39.0738444Z 221 | putpwent(spw, fd); 2024-05-06T23:00:39.0738972Z | ^
~~~ 2024-05-06T23:00:39.0739399Z | getpwent 2024-05-06T23:00:39.1114725Z cc1: all warnings being treated as errorsAnything else?
No response