Fuzzy Assessment: Part 4 - SWAMP auto changes

The previous post left us with an error from the “./configure” process stating “config.h.in” was missing. You may have remembered an autotool that can help us with “config.in.h”. If we refer to the site below we see that “autoheader” helps us with this problem.

http://www.ifnamemain.com/posts/2014/Mar/13/autoconf_automake/

Let’s add that to our build process in the package.

Section 1: Auto all the things

1. Log into the SWAMP
2. Click on “Packages”
3. Click on our package, which in our case is “OpenSSH 4.3 blog2”
4. Scroll to the bottom and click on the “Version” number
   
   
   
5. Click on “Build”
   
   
   
6. Scroll to the bottom and click “Edit Build Info”
   
   
   
7. We need to edit the “Configure command” section
   
   
   
8. Right before “autoconf” we need to add in “autoheader; ” as below
   
   
   
9. Scroll to the bottom and click “Save Build Info”. You may need to click this button twice to progress to the next screen.
10. Click on “Details”
11. Click on “Run New Assessment”
12. Change the platform to “Red Hat Enterprise Linux 32-bit” and click “Save and Run”
    
    
    
13. Click the checkbox if you want an email notification and click “Run Now”
14. Click “OK” in the notification window
15. Let’s see if this run is successful or not. The “Auto refresh” checkbox may already be checked to automatically update the screen with the progress of the build process.
16. After a short period of time, this run will also fail
17. Click the “!” exclamation point for Clang
18. This time we have much more output than in previous assessments in the failure report. We are getting closer and very soon all of the right things will be done to make a successful assessment!
19. Let’s examine the failure report
    
    
    
    < more lines from all kinds of tools working >
    
    
    
20. The error with “Ssh.bin” is interesting. Let’s take a look at it more in-depth in the next post!

Fuzzy Assessment: Part 3 - Finding our footing in the SWAMP

The previous posts set the scene of how to get packages to run in the SWAMP. We are going to fix the “configure.ac” error identified in the previous SWAMP build process.


Section 1: What seems to be the problem

1. The issue was saw in the previous post was reported in ./configure with line 15,218
   
   
   
2. However, the “./configure” program was automatically generated at runtime of the build process in the virtual machine from autoconf. So this is not a file that we can edit and fix the error above. However, we do have a “configure.ac”.
3. Go to the location in your file system where we expanded the OpenSSH archive
4. Here we can see “configure.ac”
   
   
   
5. Open up “configure.ac” in a text editor
6. If we scroll to the bottom of the file, we can see that there are only 3,825 lines of code
   
   
   
7. If there are problems, we may be able to find a bug report relating to something we encounter. Luckily for us, there was a bug to address the problem we are seeing above. Let’s review the release notes for the next minor release of OpenSSH which was 4.4.
8. We can see the release notes for OpenSSH 4.4 below
   
   https://www.openssh.com/txt/release-4.4
   
9. At the end of the release notes, we can see bugs filed in their bug tracking system. One particular bug seems to be directly related to the issue we see above.
   
   
   
10. At the top of the list, they provide a URL to their bug tracking system at http://bugzilla.mindrot.org
11. Open up a new tab or window to http://bugzilla.mindrot.org
    
    
    
12. Enter in 1203 in the search bar and click “Quick Search”. “1203” is the bug number associated with the “configure.ac” issue from the OpenSSH 4.4 release notes.
13. Quick search brings us to https://bugzilla.mindrot.org/show_bug.cgi?id=1203
14. There are a bit of detail on this page. Scroll down to “Comment 1” and click on “details”.
    
    
    
15. In the details page, we can see the code changes added in patch 2 for OpenSSH 4.3 (known as OpenSSH 4.3 p2). We can see that line 1608 was added that was a “[” character added which properly closed the block in the “configure.ac” file.
    
    
    
16. Rather than download patch 2, we are going to go another route

Section 2: Fix ‘er up

1. Browse to the file system with OpenSSH 4.3
2. Open up “configure.ac” with a text editor
3. Browse to line 1603
   
   
   
4. We can see there is no opening “[” line as we saw from the bug report earlier. We can see the previous block there are corresponding “[” and “]” characters. Let’s add in a “[” character.
5. Now the block should look like this:
   
   
   
6. Save the file and close it
7. Go up one directory and use any method available to you to archive up this new version of OpenSSH 4.3. For instance, on a Mac, right click on the folder and click “Compress”.
   
   
   
8. We should have an archived copy of OpenSSH 4.3 with our fix for “configure.ac”
   
   
   
9. Now we need to create a new package with this new version of OpenSSH or add this copy to the existing OpenSSH 4.3 blog package. Let’s just create a new package in the next section.

Section 3: Try this on for size

1. Log into the SWAMP if not already (https://www.mir-swamp.org/)
2. On the homepage, click on “Packages”
3. Click “Add New Package”
4. Give this new package a new such as “OpenSSH 4.3 blog2”, upload the new archived copy of OpenSSH 4.3, and change the version number if you’d like
   
   
   
5. Click “Next”
6. Your mileage may vary, but on a Mac, when we bundled up this archive, there are two folders from the root. There is the OpenSSH folder and a MACOX folder.
7. In the “Source” screen, click “Select”
   
   
   
8. Here we can see the two top level folders
   
   
   
9. Click on “openssh-portable-V_4_3_P1” and click “OK”
10. Now we know for sure that the build process will kick off in the right folder as we can see below
    
    
    
11. Click “Next”
12. Change the build system to “Configure+make”
13. Add in “autoconf; “ in the “Configure command” line
    
    
    
14. Add in “; make install” in the “Build options” line
    
    
    
15. We can see the commands that will be ran in the build process in the RHEL VM
    
    
    
16. Click “Save New Package”. Sometimes I have to click this button twice.
17. Click “OK” to the notification window
18. Click “Details”
    
    
    
19. Click “Run New Assessment”
    
    
    
20. Change the “Platform” to “Red Hat Enterprise Linux 32-bit” and click “Save and Run”
    
    
    
21. Check the box if you want to be emailed a notification. Click “Run Now”.
    
    
    
22. Click “OK” in the notification window
23. Now we wait for our build to process and see if this build was successful or not
24. Unfortunately, this still fails, but it’ll be a new error!
25. Click on the “!” exclamation point on the Clang line
26. Scroll to the bottom of the failure report
    
    
    
    <more lines from the configure output>
    
    
    
27. Well, now we have a different error talking about “config.h.in” missing. As this file does not exist in the file system, we need to investigate this in the next post!