I want to learn using Apple OSX command codesign.
I was able to sign an executable, and I was able to run codesign --verbose -dv <file> to verify it. But I used md5 command on the file and the hash remains the same before it got signed. Where is the signature been written to???
Related
Curl lists openSSL as an external dependency on https://curl.se/docs/libs.html.
However, if I do otool -L $(which curl) (macOS 12.5) I get the following output:
/usr/bin/curl:
/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.120.1)
No openSSL. Is this because it is only needed to compile/build curl but is not needed as an external library at runtime?
Will curl still work if I delete openSSL?
If your curl knows how to speak HTTPS or any other protocol that needs TLS, then your curl depends on a TLS library.
OpenSSL is one such a library, but curl currently supports 13 different TLS libraries that it can be built to use.
If your curl speaks a TLS protocol, it depends on one of those supported libraries. On macOS, Apple seems to have favored libressl lately but in the past they also made builds using Secure Transport directly.
The curl -V output shows which TLS library it uses in the first line, but it might take a little experience to fully understand it. TLS libraries mentioned within parentheses there are optionally enabled by the application at start.
The libraries showed in the otool output are dynamically linked at run-time. It means they need to be present and loadable when you invoke curl so that the run-time linker can load them and execute curl fine.
If you build curl yourself or download someone else's build, you can also link it statically and then all the libraries can be built into a single huge binary blob, but that is not how curl is usually built and shipped in operating systems like macOS and Linux distributions.
I am using macOS Big Sur, v11.5.2, and GDB v10.2
I have seen similar issues before, but with no clear answer.
I am trying to run a program in GDB with input redirection
sudo gdb ./executable
r < input.txt
But when I do this the shell hangs, waiting for manual input instead of reading input from the file. I have gone through the process of creating code signing certificate for GDB, running as sudo, but the same issue occurs.
I also know about MacOS's SIP and how that interferes. This link, coming from this StackOverflow post doesn't seem to offer any solutions. At least any solution that maintains the ability to use input/output redirection in GDB.
If anyone has an answer and can clearly articulate it here, I would greatly appreciate it.
Caveat: This isn't so much a complete solution as some workarounds and suggestions [that are too big to fit into a comment].
There's basically two issues:
Does gdb's r command [under macOS] allow input redirection?
Can gdb be run under sudo?
So, let's start by eliminating sudo. Does the following work:
gdb ./executable
r < input.txt
If not, either the run command's input redirection does not work or there is a bug in the executable.
Side note: For many years, I did not know that run could take I/O redirection [silly me :-)].
What I usually do/did is modify the program to allow input either from stdin or from an argument [just like cat]. Then, I'd do:
gdb ./executable
set args input.txt
run
The other issue is whether gdb can be run under sudo.
In the past, I've tried to debug a setuid executable as an ordinary user [if possible]. This eliminates the complexity of trying to run gdb and the executable as root. Sometimes this involves creating a test directory that mirrors/mimics the necessary file hierarchy [but the files are owned by the non-root user] and using (e.g.) chroot or equivalent
Much of the debug can be done this way without root privileges. For the parts that do require root, I often resort to printf debug messages--YMMV.
I'm not familiar with macOS, so I don't know how [the aformentioned] SIP will respond to the following ...
Another trick I've used is to make the executable [and a copy of gdb] into setuid programs:
cp /usr/bin/gdb /home/me/mygdb
sudo chown root /home/me/mygdb
sudo chmod 6741 /home/me/mygdb
sudo chown root /home/me/myprogram
sudo chmod 6741 /home/me/myprogram
Then, I run the modified programs. This can bypass some of the issues with using sudo directly on the target programs.
Of course, I try to make sure that there is no access to the containing directory by others. And, I remove the files when done testing.
I have Installed the complete cygwin packages and I have done the steps mentioned in this guide Link
The guide is like this:
...
Then, go to tg directory then generate Makefile.
cd tg
./configure
We need to patch Makefile and loop.c to compile in cygwin. Download this patch then untar. Then, patch in tg directory.
patch -p1 < telegram-cli-cygwin.patch
Then make
After compile is done, telegram-cli.exe will be generated in bin directory.
To run telegram-cli, type
bin/telegram-cli -k tg-server.pub
Caution: A binary compiled with Cygwin should be run in Cygwin Terminal.
I have done the all the steps successfully but when I patch the make file and the loop.c it says:
$ patch -p1 < telegram-cli-cygwin.patch
patching file Makefile
Hunk #1 succeeded at 4 with fuzz 2.
patching file loop.c
Hunk #1 FAILED at 383.
Hunk #2 succeeded at 739 with fuzz 2 (offset 105 lines).
1 out of 2 hunks FAILED -- saving rejects to file loop.c.rej
And for the next step when it says 'Then make' I have tried using the command "./configure" I dont know if I am doing this right?
And after executing the command:
bin/telegram-cli -k tg-server.pub
It says :
$ bin/telegram-cli -k tg-server.pub
-bash: bin/telegram-cli: No such file or directory
And It is right because there is no exe file created to be run. I would appreciate Any help.
I applied the patches manually after configure as #kaylum mentioned. It has to be after the configure command because the make file has to patched too and the configure command affects the make file. after that the make or make all command has to executed and the .exe file is created.
Which of the executables in the TDM bin directory will actually recognize ./configure as a valid command?
./configure is a shell script. It will be compatible with bash, sh, and maybe csh. Probably the first line in it is
#!/bin/sh
or
#!/bin/bash
If you are not on Linux or Unix, look for a configure script specifically for your operating system. Not all tools support non-Unix environments.
First thing you should read the INSTALL or README file included with the sources. Usually they describe all of the available parameters for the ./configure script (which is not "standard GCC", but specific to the project). For example for the strace project (picked it randomly, as I've cross-compiled it recently), if you want to cross-compile it with your tdm64-whatever-gcc toolchain, you have to specify it in the host parameter:
./configure --host=tdm64-whatever
I'm working to compile the Thrift 0.9.0 binary statically in a CentOS VM. I get the issue that the libthrift.a binary is not being created. I am using a vagrant box to run centos:
https://github.com/2creatives/vagrant-centos/releases/download/v6.5.1/centos65-x86_64-20131205.box
Once I ssh to the vagrant box I run the following commands:
wget https://archive.apache.org/dist/thrift/0.9.0/thrift-0.9.0.tar.gz
tar -zxvf thrift-0.9.0.tar.gz
cd thrift-0.9.0
./configure --enable-static
make
This will run but I ran a find command (sudo find / -name "*.a") on the system to see if there was any ".a" files made and the only file that was made was "libparse.a" which doesn't seem right. From my understanding it should be "libthrift.a".
Searching through the config.log file it says that it does want to build the static libraries:
configure:11944: checking whether to build static libraries
configure:11948: result: yes
Looking at more locations in the log file that has the keyword "static" reveals potential places that may be errors.
configure:9028: checking if gcc static flag -static works
configure:9056: result: no
configure:13915: checking if g++ static flag -static works
configure:13943: result: no
lt_cv_prog_compiler_static_works=no
lt_cv_prog_compiler_static_works_CXX=no
The full log file is here: http://www.filehosting.org/file/details/449460/staticThriftErrorLog.rtf
Any help is appreciated
I was able to generate the libthrift.a file. After running the command for the extra dependancies mentioned in my comment I forgot to run the make command. So after doing the make command I found the libthrift.a file in "thrift-0.9.0/lib/cpp/.libs/". Interestingly enough, even after fixing the dependencies, config.log still had the same potential problem areas regarding the gcc/g++ static flag and static compiler.
Specifically the dependency command is as follows:
sudo yum install automake libtool flex bison pkgconfig gcc-c++ boost-devel libevent-devel zlib-devel python-devel ruby-devel openssl-devel.x86_64
Edit: After getting advice on the Jira ticket, it turns out the specific vagrant box I was using was causing the errors. Using the VM he linked I was able to successfully build Thrift using the provided instructions. (Jira ticket https://issues.apache.org/jira/browse/THRIFT-2559)