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!